A friend (who shall remain nameless) recently told me his company interviewed a competent database developer and DBA. All seemed in agreement an offer would be forthcoming until the very end of the recruiting process. At that time, someone made the comment "we don't need a DBA."
It would be notable if this sentiment wasn't so widespread - but I see it often. How often? Well, I would have to tell you how I see it to qualify that statement:
You see, people rarely say to me "We don't need you because we don't need a DBA." Mostly I see it in their applications - many of them prominent companies in which you may even own stock. I can tell when I examine their schema. I can see it when I execute Profiler against their SQL Server database.
Now, there are lots of reasons to design a denormalized schema. And there are lots of reasons to encapsulate the business rules in code. This is not what I'm talking about - though some of these systems would clearly perform better (or at all, in extreme cases) if they took advantage of better design patterns.
I'm talking about designs where this much is obvious:
1. At least two people designed the data layer; and
2. They did not communicate during the process.
Often, enterprise-level database design is shoveled onto developers as a secondary task. No, I'm not making this up - it's too tragic to joke about. There are developers out there who can handle this task, but they are few and far between. (Before I became a SQL Server DBA I was a developer who thought I was a SQL Server DBA...)
There will doubtless be readers who can provide examples of how their enterprise application was built by junior developers who did the database and code work and whose systems are performing just fine. I'm happy for you and sincerely hope the system scales.
Designing a scalable solution - database, application, or architecture - is one of those things that consumes time, thinking, resources, and money during the early phases of an enterprise development cycle. But it is - hands down - one of the best (if not the best) investments in the solution. And in today's market, scalability is as optional as security. And like security, a scalable design is not something you "add later." It's not part of the foundation - it is the foundation.
My experiences with designing scalable solutions has proven to me there is no free lunch nor any shortcuts that work. If anyone - me included - skips the work of designing for scalability, there comes a day when they (or I) must pay the fiddler. From what I hear and have experienced, designing in this fashion is most often sacrificed on the altar of a deadline. Trust me, if it falls apart in six weeks or six months, you haven't saved any time - and you may have lost a customer.
Someone told me this and I remember because it has proven true several times over: "Deliver quality late, no one remembers. Deliver junk on time, no one forgets."
If you're building (or upgrading to) cutting edge technology, you need a DBA.
:{> Andy
Technorati Tags: Software Business scalable database design quality