> 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 keys. > 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. PB [sql, mysql] --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
