Re: Surrogate Key vs Production Key

>> Yeah, it's gonna be interesting to watch how many massive updates
those changes are gonna mean for people using the codes as natural keys. Think of all the FKs that will need tweaking and updating. What a flexible design... <<

I hate to tell you this, but even if you did not use them as keys, the industry standard codes will have to be maintained and updated. But if you used an exposed physical locator, then you will have to co-ordinate the locator and the new values.

In a good SQL engine I have an ALTER DOMAIN statement and ON UPDATE CASCADE to a lot of my work.

>> In other words: an implicit "structure" as opposed to an explicit
specification. I can hear the alarm sirens already! A single attribute (the base of any column used as a PK or FK) should not have an inherent "structure". If it does, then there is some normalization missing in there somewhere. <<

I am trying to figure where that idea came from. The main characteristic of a key is that it is unique and invariant anywhere it appears. Then there is familarity and some others I have forgotten off the top of my head.

A data element which can be verified and validated leads to data quality. It is a solution, not a problem. Do you really think that, say, ISBNs would be better without a check digit? If they did not have the publisher codes in them? Would books be easier to locate? Would data entry errors increase or decrease if they were a random number of varying length? Received on Thu Oct 14 2004 - 21:54:33 CDT