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