A couple of months ago I commented on Eric Wise's post titled Know Your Role, wherein Eric expounded on the need for a DBA on software projects. I took exception to the rule that DBA's are required, which sparked several comments and blog posts that seemed to fall just short of calling me an idiot for thinking this way. I don't have any real objections to having my ideas questioned... I'm not arrogant enough to think that I know everything. So I took a step back and thought about it for a while, and here's what I came up with.
I believe that one of the only absolute truths that can be stated is that there are no absolutes.
Very rarely is there a clear cut line drawn in the sand. One of my comments drew upon the experience I have gained as a developer on a large project. We have no formal DBA who controls or greatly influences our database design. We do have lots of developers with a great deal of experience designing systems, as well as several who were DBA's or database programmers in past lives. I asked around a bit, trying to get a feel for what the actual SQL gurus thought of our database design. The general consensus was that it was pretty good. Not perfect, but better than most.
Along the way, I did hear a few good stories about DBA's which may account for the developer comments paraphrased in Eric's post ("DBAs only get in the way" and "I'm not doing anything fancy, I don't need no stinking DBA"). In the minds of some of the developers I talked to, the term DBA is a synonym for difficult. I heard tales of entire database designs being entrusted to one sacred individual who was the only person authorized to make changes because someone, somewhere decided that they knew what was best. Tales of insane hacks being made to the application code to work around a schema that couldn't be changed, yet no longer represented the business. I'm guessing that this extreme is what has so many developers spooked.
Now I'm sure someone can point out the inverse scenario... You'll definitely find several if you browse through TheDailyWtf.com archives. The fact of the matter is that "DBA" is just a label. As is "Developer." Having a bad DBA controlling the database on a project may be worse than not having one at all. Having a good DBA who fits in with the team, enabling them to build the system to the specification of the clients with as little friction as possible is definitely an asset.
I still believe that most projects don't need someone to fill the DBA role. They need a group of developers who know what they're doing, from the database up to the presentation layer. I don't think that good database design is that hard for someone who's a little clueful, but it's always a good idea to have everyone involved in the conversation throughout the development process. The more eyes on the problem, the less chance there is of something being missed.
I hope this makes sense, as I'm not sure I've presented my ideas exactly the way I intended. Keep in mind that my frame of reference for this post is based on green-field development of a project. I do realize that database lock downs may be required in some situations. I'm just taking exception to a supposed rule.