> Really, the issue is that you don't want a primary key that is volatile.
> It doesn't matter if it has business meaning.
Or user meaning, ie users find them useful signs. Fair enough, but if you
take that as a rationale for choosing PK values that begin by having meaning
to users, you leave your PKs prone to uniqueness failure by whatever
process, external to your DB, that generates them.
> For example, a social
> security number is a pretty decent pk for a table of people.
There are lots of forged SSNs in the US, probably that's true in other
countries, in which case there are SSN dupes, so they are not good candidate
> Of course,
> the whole primary key concept is not really part of relational theory,
> which just talks about candidate keys.
Most expositions of relational theory disagree, eg C.J Date's version of the
12 Rules (An Introduction to Database Systems, ed 5, pp 389-393) expresses
the guaranteed access rule as: each and every datum (atomic value) in a
relational data base is guaranteed to be logically accessible by resorting
to a combination of table name, primary key value and column name.