Re: Why an organization would need an enterprise DB team

On 3/18/07, Robert Freeman <robertgfreeman@xxxxxxxxx> wrote:


 Just to chime in a bit since this is somewhat related to a presentation
I'm doing at Collaborate...

I agree with Dennis, we have to get closer to where the work is! We old
DBA/DA types need to keep up. Data modeling really has not kept up with
Object modeling well, and now with evolutionary development methods like
Agile out there, we really are going to have to get caught up or we are
going to find we will be left behind. I don't think that companies are going
to be content to slow down application development so the database
designer/architect/developer can "Get it right" up front anymore and we have
to find a better way to work.



... and Object modeling has not lived up to the hype.

Programming paradigms come and go, Agile is just another one of these.
If you need to learn it to work with a development team, then by all means
do so.

Relational theory is the basis for representing data.  No one has so far
come
up with anything to successfully supercede it.



I have to admit that in the last year my approach to database development
and design has changed a great deal (and I was a hard sell)... I now believe
that it is *HYPER* CRITICAL to success that the development DBA be in the
same work area as the development staff (thats not to say you can't have a
separate production team if you like, or perhaps a separate core team
providing core database services).




I haven't been heavily involved in development for about 5 years, so you may
be right about it being critical, if by that you mean 'staying employed'.

I also believe that we have to embrace the concept that there is no way you

are going to get everything right up-front and that data driven database
development, in many cases (note, I don't say all cases) is not the best and
most cost efficient way of doing things. I will also probably sound like a
total heretic when I say that passing some of the DDL responsibilities to
the developers is critical to rapid and successful development.



"Why is data modeling needed?  The main reason is that systems developers
are so bad at building files and databases".  George Tilmann - A Practical
Guide to Logical Data Modeling - McGraw Hill 1993

That hasn't changed much in 14 years.

Much of this ignorance of how an efficient (as in scalable) database should
work is due to the Microsoft 'black box' programming methods.  Developers
don't know many of the building blocks they use really work,  and are not
encourage to find out how things work.

You don't need to know all the internals, but you do need some idea of how
things work to use them efficiently.

Here's and example of database design wisdom from MS, found at
http://support.microsoft.com/kb/100139

As with many formal rules and specifications, real world scenarios do not
always allow for perfect compliance. In general, normalization requires
additional tables and some customers find this cumbersome. If you decide to
violate one of the first three rules of normalization, make sure that your
application anticipates any problems that could occur, such as redundant
data and inconsistent dependencies.


Developers reading this will likely dismiss normalization as unnecessary and
wasted effort.

--
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

Other related posts: