Re: Surrogate Key vs Production Key

"Cris Carampa" <cris119_at_operamail.com> wrote in message news:ckirpr$h64$1_at_lacerta.tiscalinet.it...
| Mark C. Stock wrote:
|
| > but when establishing the data model, introducing a surrogate key column
to
| > replace a natural key column structure seriously weakens the data model
and
| > often hides (or impedes discovery of) very important facts about the
| > business
|
| Good point. But what happens if the natural key is made of more than one
| column? Do you still use it (and have all the child tables inherit it -
| this surely enforces the business rules but wastes hd space) or do you
| define a surrogate key instead?
|
| Kind regards,
|
| --
| Cris Carampa (spamto:cris119_at_operamail.com)
|
| The World is Case Sensitive.
| Only the Evil Empire is cAsE inSenSitivE.

actually, i've found that keeping the compound PK and propagating it to the child table FKs often makes coding easier as fewer joins are required to access data in context (i.e., retrieving great-great-grandchild records without having to walk the hierarchy from the great-great grandparent), and code to enforce constraints is simplified (or becomes declarative)

as with anything, the implementation decision is on a case by case basis -- but conserving disk space is not a major consideration

note that i also advocate use of an alternate system-assigned key, or GUID, in every significant table, as well as a row-version column -- but those are both implementation considerations, not data-modeling considerations, which is what i was focusing on in my post

++ mcs Received on Wed Oct 13 2004 - 07:05:17 CDT