Surrogate vs. Natural Primary keys

I am stuck in the middle between developers and a DBA. The developers feel that every table in a database needs to have a surrogate primary key generated by a sequence and a unique index assigned to any possible natural keys in order to eliminate redundancy. The reason is that their "framework" uses a code generator and it is much easier and faster to develop their apps. The DBA thinks that this is a bad practice because it is a waste of disk space and performance having to generate unnecessary indexes.
This wouldn't be a problem for a single database, but it is happening on dozens of databases and applications and we are limited to one server for all of our instances.
An example of what I am talking about.

Account                              Account_detail
---------                            ----------------
account_id pk                        account_detail_id pk
account_num uk                       account_id        fk
                                     account_detail_num

This in itself is not a bad design as long as RI is enforced and there will always be situations where a surrogate key is the best way to go. The biggest problem I have personally had with this approach is while using SQL*Loader and being forced to chose a conventional path load because it will not allow you to insert sequence values in a direct path. This turned a 4 minute job into 30. I tried creating a staging table so that I could do a direct path load but then the insert script took just as long.

It seems to me that this boils down to faster development vs. quality data management. Is this a common practice?

BG Received on Thu Oct 13 2005 - 12:15:32 CDT