Re: Separate foreign keys with shared ID space

After a long battle with technology, "Marshall Spight" <mspight_at_dnai.com>, an earthling, wrote:
> "Christian Antognini" <christian.antognini_at_trivadis.com> wrote in message news:410affcf$1_at_post.usenet.com...
>>
>> A PK should have no business meaning.
>
> Says who? Can you justify this statement?

A good reason for this is that business meanings can change, but primary keys can't.

A typical example of this is the use of the government "social insurance/security" as a PK. It's not _supposed_ to change, but it can.

Supposing somebody does a "steal my identity" thing using my SIN/SSN number, and things go so gravely badly that the government actually decides that it is a better thing to give me a new number, that _breaks_ the use of SSN/SIN as a primary key.

If we fabricate a number of our own as an "employee ID," that's well and good, until such time as there is a corporate merger that has conflicting ID spaces so that peoples' IDs have to change.

-- 
(format nil "~S_at_~S" "cbbrowne" "acm.org")
http://cbbrowne.com/info/sgml.html
"That's  convenience, not cracker-proofing.   Security is  an emergent
property, not a feature." -- void <float_at_interport.net>