Editing Primary key (section)

==Surrogate keys==
{{Main article|Surrogate key}}
In some circumstances the natural key that uniquely identifies a tuple in a relation may be cumbersome to use for software development. For example, it may involve multiple columns or large text fields. In such cases, a [[surrogate key]] can be used instead as the primary key. In other situations 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.

Since primary keys exist primarily as a convenience to the programmer, surrogate primary keys are often used, in many cases exclusively, in database application design.

Due to the popularity of surrogate primary keys, many developers and in some cases even theoreticians have come to regard surrogate primary keys as an inalienable part of the relational data model. This is largely due to a migration of principles from the object-oriented programming model to the relational model, creating the hybrid object–relational model. In the [[object–relational mapping|ORM]] like [[active record pattern]], these additional restrictions are placed on primary keys:

* Primary keys should be immutable, that is, never changed or re-used; they should be deleted along with the associated record.
* Primary keys should be anonymous integer or numeric identifiers.

However, neither of these restrictions is part of the relational model or any SQL standard. [[Due diligence]] should be applied when deciding on the immutability of primary key values during database and application design. Some database systems even imply that values in primary key columns cannot be changed using the <code>UPDATE</code> SQL statement.{{Citation needed|date=January 2009}}