Wow, I could expound for hours on this one. And what excellent fodder for a forum of experienced DBA's who have "been there - done that". There have already been some excellent replies on this article so I won't won't relate the volumes of my own experiences on this subject - the several times when I've been called in to "rescue" the work of some wannabe DBA that has propagated a house of cards and bolted, or the work of a bevvy of programmers that have pounded-in some application with schemas and code that could only be considered server abuse. There are just a couple of points I wanted to chime in on:

Anticipate the misconceptions toward your expertise and the value of the work that you do, and evangelize SQL best practices with kid-gloves and lavish diplomacy. You must never report your findings to any member of your client company with words like, "this code is awful" or "this is just wrong", even if you speak the terrible truth. Strive to teach and bring them over to your side by shining a light not so much why their way is wrong but why your way is better. If you're as good as you say you are the reasoning you provide will become abundantly clear to them, and will smooth the way toward reception of your ideas, even if there is some cost involved (which of course, is almost always the case!). Nobody wants to hear that their work (or even the work of a former employee) was of poor quality, even if that is obviously the case and is directly attributable to the reason you're here. You must take on the role of salesman, teacher and diplomat as much as SQL guru, and with any luck the thought bubble will begin to form above their heads, "Hey, maybe it really does take a specialist to keep the back-end healthy, protected, available, agile, etc."

The other thing I wanted to say is that the reason this scenario is so common is certainly at least partly Microsoft's fault. In short, they've made it very easy to build a bad database. When you look at all the "vigilante" data storage projects out there built with Access, Excel files and build-and-forget SQL databases and the fact that many of the tools are largely GUI-based and very intuitive, this scenario is indeed, almost inevitable. Every business of every size and description needs to store and retrieve data, and they will of course want to do it in the cheapest, fastest and easiest way possible. This combined with the fact that almost every IT discipline requires at least some training in SQL Server, which means that every programmer out there will at some point hear the words, "can you build the back-end for us?" and consider him/herself perfectly capable of doing so. This is not to say that a well designed schema cannot be built by a programmer, but at some point during the life span of that solution (if it makes it to production) I can almost guarantee that it will need a good DBA to make sure it is well protected, scales properly with growth, well tuned and highly available down the road. And of course we can only hope that the original author anticipated the need to do all these things in his/her original design! 😉