A bit simplistic, but in a nutshelll
They are used for different things. A natural PK is used for data
integrity purposes, and if it is a single attr, it can also be a
performance enhancing index.
An artificial key is used to speed up queries, by allowing joins on a
single indexed attribut
While this statement is accurate, it isn't very precise. Needs change.
Requirements change. Usage changes. Any one of these changes can
invalidate a very correct initial analysis. A wise designer anticipates
change to minimize impact on both current work *and* future development
effort. Artific
[EMAIL PROTECTED] wrote:
In the book "Practical Issues in Database Management", Fabian Pascal
notes three reasons for choosing one PK over another - familiarity,
stability, and simplicity.
He notes further that those influenced by OO db design tend to use
simple, surrogate keys for all PKs in al
On Thursday 2006-06-08 05:48, [EMAIL PROTECTED] wrote:
> What am I missing? Why use a composite key *ever* aside from
> "familiarity?" Could someone give a real-world example where
> "familiarity" is a compelling reason to choose a composite PK, and
> trumps stability and simplicity?
Another "fam
If one decides to use a composite key, beyond how many attributes
should one seriously consider creating a surrogate key instead? 4? 5?
Less? I have seen a composite key composed of 5 attributes and thought
- why? What's the value over a surrogate key?
I guess choosing a candidate key (presuming t
