Primary Key versus Unique Constraint?

Question

I\'m currently designing a brand new database. In school, we always learned to put a primary key in each table.

I read a lot of articles/discussions/newsgroups posts

Answer 1

I submit that you may need both. Primary keys by nature need to be unique and not nullable. They are often surrogate keys as integers create faster joins than character fileds and especially than multiple field character joins. However, as these are often autogenerated, they do not guarantee uniqueness of the data record excluding the id itself. If your table has a natural key that should be unique, you should have a unique index on it to prevent data entry of duplicates. This is a basic data integrity requirement.

Edited to add: It is also a real problem that real world data often does not have a natural key that truly guarantees uniqueness in a normalized table structure, especially if the database is people centered. Names, even name, address and phone number combined (think father and son in the same medical practice) are not necessarily unique.

Answer 2

Unless the table is a temporary table to stage the data while you work on it, you always want to put a primary key on the table and here's why:

1 - a unique constraint can allow nulls but a primary key never allows nulls. If you run a query with a join on columns with null values you eliminate those rows from the resulting data set because null is not equal to null. This is how even big companies can make accounting errors and have to restate their profits. Their queries didn't show certain rows that should have been included in the total because there were null values in some of the columns of their unique index. Shoulda used a primary key.

2 - a unique index will automatically be placed on the primary key, so you don't have to create one.

3 - most database engines will automatically put a clustered index on the primary key, making queries faster because the rows are stored contiguously in the data blocks. (This can be altered to place the clustered index on a different index if that would speed up the queries.) If a table doesn't have a clustered index, the rows won't be stored contiguously in the data blocks, making the queries slower because the read/write head has to travel all over the disk to pick up the data.

4 - many front end development environments require a primary key in order to update the table or make deletions.

Answer 3

posts saying that it's better to use unique constraint (aka unique index for some db) instead of PK

i guess that the only point here is the same old discussion "natural vs surrogate keys", because unique indexes and pk´s are the same thing.

translating:

posts saying that it's better to use natural key instead of surrogate key

Answer 4

Can you provide references to these articles?

I see no reason to change the tried and true methods. After all, Primary Keys are a fundamental design feature of relational databases.

Using UNIQUE to serve the same purpose sounds really hackish to me. What is their rationale?

Edit: My attention just got drawn back to this old answer. Perhaps the discussion that you read regarding PK vs. UNIQUE dealt with people making something a PK for the sole purpose of enforcing uniqueness on it. The answer to this is, If it IS a key, then make it key, otherwise make it UNIQUE.

Answer 5

PRIMARY KEY

1. Null It doesn’t allow Null values. Because of this we refer PRIMARY KEY = UNIQUE KEY + Not Null CONSTRAINT. 2. INDEX By default it adds a clustered index. 3. LIMIT A table can have only one PRIMARY KEY Column[s].

UNIQUE KEY

1. Null Allows Null value. But only one Null value. 2. INDEX By default it adds a UNIQUE non-clustered index. 3. LIMIT A table can have more than one UNIQUE Key Column[s].

Answer 6

It would be very rare denormalization that would make you want to have a table without a primary key. Primary keys have unique constraints automatically just by their nature as the PK.

A unique constraint would be used when you want to guarantee uniqueness in a column in ADDITION to the primary key.

The rule of always have a PK is a good one.

http://msdn.microsoft.com/en-us/library/ms191166.aspx