Re: Surrogate Key vs Production Key

jcelko212_at_earthlink.net (--CELKO--) wrote in message news:<18c7b3c2.0410141854.62dc56c8_at_posting.google.com>...
> >> 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?

juat a quick thank you, Joe, for carrying on this discussion so well.

I lacked the patience and the time.
  Ed Received on Wed Oct 20 2004 - 13:32:26 CDT