Bruce G. wrote:
> 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
>
Not again...
Check out the dizwell forum (accessible via www.dizwell.com)
--
Regards,
Frank van Bortel
Top-posting is one way to shut me up...
Received on Thu Oct 13 2005 - 14:28:03 CDT
