Primary key should be chosen so as attributes never change

database-designprimary-key

I was reading about keys in this DatabaseSystems book

The primary key should be chosen such that its attributes are never, or very rarely, changed. For instance, the address field of a person should not be part of the primary key, since it is likely to change.

Can someone provide an explanation to this ?

Is it because a change might be a danger to its inherent requirement of being unique ?

I cant really make out the proper logic for this.

Best Answer

Keys are identifiers. They permit database users to identify the specific things about which information is being recorded in a database. If the values of key attributes are subject to change then there may be a risk of misidentification, particularly if the identifying information is also recorded elsewhere outside the database (e.g. in other databases, documents or in the mind of the users).

Sensible criteria to consider when choosing what keys to use are: Stability, Simplicity and Familiarity. These are good criteria for choosing any key, not just "primary" keys (the designation of a "primary" key is essentially arbitrary and a matter of convention or convenience - it doesn't mean those keys are fundamentally different to any other).

Stability, simplicity and familiarity are of course all subjective and relative criteria. Any attribute, whether key or not, might need to change and sometimes the ability to change a key attribute is a necessary part of maintaining accurate data and the correct operation of the systems that depend on the data. Very often there is no way to foresee a future requirement that may require such a change. It isn't necessary or even achievable to expect all keys never to change.

Uniqueness isn't really the issue because uniqueness needs to be enforced whether key values change or not. The uniqueness is implicit in the fact that it is a key and is maintained as such by the DBMS.