Primary key
Relational databases concept
- 5 min read
- 4 chapters
Learn it on Lably
Examples of natural keys that could be suitable primary keys include data that is already by definition unique to all items in the table such as a national identification number attribute for person records, or the combination of a timestamp attribute with a location attribute for event records.
More formally, a primary key is a specific choice of a minimal set of attributes that uniquely specify a tuple (row) in a relation (table). A primary key is a choice of a candidate key (a minimal superkey); any other candidate key is an alternate key.
Design
In relational database terms, a primary key does not differ in form or function from a key that isn't primary. In practice, various motivations may determine the choice of any one key as primary over another. The designation of a primary key may indicate the "preferred" identifier for data in the table, or that the primary key is to be used for foreign key references from other tables or it may indicate some other technical rather than semantic feature of the table. Some languages and software have special syntax features that can be used to identify a primary key as such (e.g. the PRIMARY KEY constraint in SQL).
The relational model, as expressed through relational calculus and relational algebra, does not distinguish between primary keys and other kinds of keys. Primary keys were added to the SQL standard mainly as a convenience to the application programmer.
Primary keys can be an integer that is incremented, a universally unique identifier (UUID) or can be generated using Hi/Lo algorithm.
Sign in to keep reading
3 more chapters are free with a Lably account.
Defining primary keys in SQL
Primary keys are defined in the ISO SQL Standard, through the PRIMARY KEY constraint. The syntax to add such a constraint to an existing table is defined in SQL:2003 like this:
<span id="mwMw"></span><span class="k" id="mwNA">ALTER</span><span class="w" id="mwNQ"> </span><span class="k" id="mwNg">TABLE</span><span class="w" id="mwNw"> </span><span class="o" id="mwOA"><</span><span class="k" id="mwOQ">table</span><span class="w" id="mwOg"> </span><span class="n" id="mwOw">identifier</span><span class="o" id="mwPA">></span><span class="w" id="mwPQ"> </span> <span class="w" id="mwPg"> </span><span class="k" id="mwPw">ADD</span><span class="w" id="mwQA"> </span><span class="p" id="mwQQ">[</span><span class="w" id="mwQg"> </span><span class="k" id="mwQw">CONSTRAINT</span><span class="w" id="mwRA"> </span><span class="o" id="mwRQ"><</span><span class="k" id="mwRg">constraint</span><span class="w" id="mwRw"> </span><span class="n" id="mwSA">identifier</span><span class="o" id="mwSQ">></span><span class="w" id="mwSg"> </span><span class="p" id="mwSw">]</span><span class="w" id="mwTA"> </span> <span class="w" id="mwTQ"> </span><span class="k" id="mwTg">PRIMARY</span><span class="w" id="mwTw"> </span><span class="k" id="mwUA">KEY</span><span class="w" id="mwUQ"> </span><span class="p" id="mwUg">(</span><span class="w" id="mwUw"> </span><span class="o" id="mwVA"><</span><span class="k" id="mwVQ">column</span><span class="w" id="mwVg"> </span><span class="n" id="mwVw">name</span><span class="o" id="mwWA">></span><span class="w" id="mwWQ"> </span><span class="p" id="mwWg">[</span><span class="w" id="mwWw"> </span><span class="err" id="mwXA">{</span><span class="p" id="mwXQ">,</span><span class="w" id="mwXg"> </span><span class="o" id="mwXw"><</span><span class="k" id="mwYA">column</span><span class="w" id="mwYQ"> </span><span class="n" id="mwYg">name</span><span class="o" id="mwYw">></span><span class="w" id="mwZA"> </span><span class="err" id="mwZQ">}</span><span class="p" id="mwZg">...</span><span class="w" id="mwZw"> </span><span class="p" id="mwaA">]</span><span class="w" id="mwaQ"> </span><span class="p" id="mwag">)</span>The primary key can also be specified directly during table creation. In the SQL Standard, primary keys may consist of one or multiple columns. Each column participating in the primary key is implicitly defined as NOT NULL. Note that some RDBMS require explicitly marking primary key columns as NOT NULL.
<span id="mwcg"></span><span class="k" id="mwcw">CREATE</span><span class="w" id="mwdA"> </span><span class="k" id="mwdQ">TABLE</span><span class="w" id="mwdg"> </span><span class="k" id="mwdw">table_name</span><span class="w" id="mweA"> </span><span class="p" id="mweQ">(</span> <span class="w" id="mweg"> </span> <span class="w" id="mwew"> </span><span class="p" id="mwfA">...</span> <span class="p" id="mwfQ">)</span>
If the primary key consists only of a single column, the column can be marked as such using the following syntax:
<span id="mwgQ"></span><span class="k" id="mwgg">CREATE</span><span class="w" id="mwgw"> </span><span class="k" id="mwhA">TABLE</span><span class="w" id="mwhQ"> </span><span class="k" id="mwhg">table_name</span><span class="w" id="mwhw"> </span><span class="p" id="mwiA">(</span> <span class="w" id="mwiQ"> </span><span class="n" id="mwig">id_col</span><span class="w" id="mwiw"> </span><span class="nb" id="mwjA">INT</span><span class="w" id="mwjQ"> </span><span class="k" id="mwjg">PRIMARY</span><span class="w" id="mwjw"> </span><span class="k" id="mwkA">KEY</span><span class="p" id="mwkQ">,</span> <span class="w" id="mwkg"> </span><span class="n" id="mwkw">col2</span><span class="w" id="mwlA"> </span><span class="nb" id="mwlQ">CHARACTER</span><span class="w" id="mwlg"> </span><span class="nb" id="mwlw">VARYING</span><span class="p" id="mwmA">(</span><span class="mi" id="mwmQ">20</span><span class="p" id="mwmg">),</span> <span class="w" id="mwmw"> </span><span class="p" id="mwnA">...</span> <span class="p" id="mwnQ">)</span>
Surrogate keys
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 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 UPDATE SQL statement.
Alternate key
Typically, one candidate key is chosen as the primary key. Other candidate keys become alternate keys, each of which may have a UNIQUE constraint assigned to it in order to prevent duplicates (a duplicate entry is not valid in a unique column).
Alternate keys may be used like the primary key when doing a single-table select or when filtering in a where clause, but are not typically used to join multiple tables.