Re: Surrogate Key vs Production Key

Noons wrote:

> DA Morgan <damorgan_at_x.washington.edu> wrote in message news:<1098424093.675630_at_yasure>...
>
>

>>And just like with Cobol and Y2K ... hopefully you'll have
>>a different job when the duplicates are found and it won't
>>be your problem.

Of course nothing does. And whenever I use surrogate keys I always try to protect my data with a unique constraint.

But lets acknowledge we are talking about two more constraints (unique and not null) plus one more index. Each with its attendant overhead. More not null check constraints if it is the unique index is multicolumn and you still have the original issue that if you were to merge your data with other data ... the surrogate keys will be duplicated in the other system.

Understand, please, I use surrogate keys daily. I just always decide to use them after eliminating the use of a natural key ... not a first choice. There is a place in a reasonable design for both. Natural keys just require applying synapse as well as syntax.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)