Primary Key Article Index for
Primary 		Website Links For
Primary 		 

Information About

Primary Key
APPAREL
BABY
BEAUTY
BOOKS
CAR TOYS
CELL PHONES
DVD'S
ELECTRONICS
GOURMET FOOD
GROCERIES
HEALTH & PERSONAL
HOME & GARDEN
JEWELRY
MUSIC
MUSIC INSTRUMENTS
OFFICE PRODUCTS
SOFTWARE
SPORTING GOODS
TOOLS & HARDWARE
TOYS
VIDEO GAMES
SHOPPING HOME
MORE SHOPPING...



In the Relational Model of Data , a primary key is a Candidate Key chosen as the main method of uniquely identifying a Tuple in a Relation . Practical telephone books and dictionaries cannot use names or words or Dewey Decimal System numbers as candidate keys because they do not uniquely identify telephone numbers or words.

In some Design Situation s it is impossible to find a Natural Key that uniquely identifies a tuple in a relation. A Surrogate Key can be used as the primary key. In other Situation s there may be more than one candidate key for a relation, and no candidate key is obviously preferred. A surrogate key may be used as the primary key to avoid giving one candidate key artificial primacy over the others.

In addition to the requirement that the primary key be a candidate key, there are several other factors which may make a particular choice of key better than others for a given relation:
  • The primary key should be Immutable , meaning that its value should not be changed during the course of normal operations of the database. (Recall that a primary key is the means of uniquely ''identifying'' a tuple, and that Identity , by definition, never changes.) This avoids the problem of Dangling Reference s or ''orphan records'' created by other relations referring to a tuple whose primary key has changed. If the primary key is immutable, this can never happen.

  • Candidate keys have the advantage of uniquely identifying a row without requiring additional storage space. However, it is exceedingly rare that a candidate key remains immutable throughout the life of the database, and changing keys may necessitate significant application reprogramming. As a result, a surrogate key taken from a randomly generated 32-bit integer and validated for redundancy works exceedingly well. They require only four bytes of storage space each, permit just over four billion combinations, and, since they have no meaning in and of themselves, need never be changed.

  • The primary key should generally be short to minimize the amount of data that needs to be stored by other relations that reference it. If no single domain of the relvar qualifies as a key, a Compound Key may be appropriate. Physical constraints on the implementation may suggest adding a shorter surrogate key, in order to reduce the redundant storage used. (However, this is a physical design consideration, and some database management systems may be better than others in this regard.)



SEE ALSO