A better way to think about it is that we don't need a traditional
DBA, what we need is an agile DBA. See www.agiledata.org for some
ideas, including a range of techniques, for agile dbas.
The Cutter group will have a management issue on agile database
techniques coming out in December which I'm editing and which Pramod
and I have a joint article in. Our article overviews agile data
techniques such as refactoring, TDD, sandboxes, and so on. Three
articles describe case studies, one where an agile dba came into a
project about a year into it and fixed a few things up (but if I
remember correctly didn't need to institute any new modeling
activities), another where an agile dba had to focus on TDD, and
another where there was no DBA needed at all due to superior
tooling. All of these articles were written by people with actual
experience on agile projects. A fifth article, written by someone
without agile experience, argued for the need for a lot more modeling
than I would recommend (I'm the guy behind Agile Modeling,
The sorts of things that Pramod wrote about in the article below do
seem to work very well in practice. I highly recommend that data
professionals take them seriously.
At 01:07 PM 11/4/2005, you wrote:
>I read your article below.. But I have to take exception with
>the "You don't need a DBA" section. Every company doing database
>work needs someone who has more than a "passing interest" in
>databases. I cannot believe the companies I go to that have tables
>with no structure, no indexes and no concept of normal form. You may
>think "I'm a startup we will just redo the database later" but once
>the snowball starts rolling down the hill it gets really big and is
>hard to stop. I believe that an hour of DB design up front saves
>100's of hours down the road!!
>--- In agileDatabases@yahoogroups.com, "psadalage <psadalage@y...>"
> > My colleague Martin Fowler and I have written an article on
> > Evolutionary Database Design see:
> > http://www.martinfowler.com/articles/evodb.html