Someone asked me this question on an interview...
-
11and you were not able to answer it? what a loser! me neither. – Alex Gordon Jun 01 '10 at 19:55
-
1possible duplicate of [UNIQUE and PRIMARY KEY](http://stackoverflow.com/questions/2452399/unique-and-primary-key) – Vijay Feb 22 '12 at 09:11
15 Answers
Primary keys can't be null. Unique keys can.

- 767
- 1
- 4
- 7
-
7+1 This is the crucial difference. It means that the columns in the primary key can address every row unambiguously, but the columns unique key can't (unless they are coincidentally NOT NULL). – Bill Karwin Aug 20 '09 at 20:37
-
Reading this question (http://stackoverflow.com/questions/767657/how-do-i-create-unique-constraint-that-also-allows-nulls-in-sql-server), and the answers, it looks like unique constrain can not have nulls. So, I'm confused. Is this MSSQL specific, or what? – Sunny Milenov Feb 18 '10 at 20:16
A primary key is a unique field on a table but it is special in the sense that the table considers that row as its key. This means that other tables can use this field to create foreign key relationships to themselves.
A unique constraint simply means that a particular field must be unique.

- 23
- 6

- 344,730
- 71
- 640
- 635
-
12The primary key of a row is the way that the database recognizes an individual row. It can consist of one or more columns, which together must also be unique. – TheJacobTaylor Aug 20 '09 at 20:27
-
12
-
12
-
16
-
9Its the old square rectangle rule. A primary key is a unique constraint but a unique constraint isn't a primary key. Additionally a PK by definition cannot be null where a unique constraint could be null. – James Collins Jan 12 '10 at 19:40
-
I just experience something today for Oracle. I was required to create a DDL for new table need make one of timestamp with timezone field as primary key. Oracle didn't allow it. The one solution become make unique constraint behavior as primary key since Oracle accept timestamp with timezone field as part of unique constraint. – Hongtao Jan 22 '16 at 16:17
-
1"the table considers that row its key" - what does that even mean ?? – onedaywhen Jul 11 '16 at 09:25
-
Because a unique constraint means that a simple key can be used to identify the row, how is a simple key different to a primary key other than the fact that the database is using the primary key to identify rows and not the simple keys? – guymid Dec 08 '16 at 09:23
- Primary key can not be null but unique can have only one null value.
- Primary key create the cluster index automatically but unique key not.
- A table can have only one primary key but unique key more than one.

- 217
- 1
- 4
- 8
-
1+1 Good answer. Note that your first point applies to SQL Server, but not to MySQL, for example. – Mark Byers May 26 '10 at 20:46
-
2Your first point is not correct as regards the SQL standard and the second is irrelevant as regards the SQL standard (but both are true of SQL Server). – onedaywhen Feb 22 '12 at 08:37
TL;DR Much can be implied by PRIMARY KEY
(uniqueness, reference-able, non-null-ness, clustering, etc) but nothing that can't be stated explicitly using UNIQUE
.
I suggest that if you are the kind of coder who likes the convenience of SELECT * FROM...
without having to list out all those pesky columns then PRIMARY KEY
is just the thing for you.
a relvar can have several keys, but we choose just one for underlining and call that one the primary key. The choice is arbitrary, so the concept of primary is not really very important from a logical point of view. The general concept of key, however, is very important! The term candidate key means exactly the same as key (i.e., the addition of candidate has no real significance—it was proposed by Ted Codd because he regarded each key as a candidate for being nominated as the primary key)... SQL allows a subset of a table's columns to be declared as a key for that table. It also allows one of them to be nominated as the primary key. Specifying a key to be primary makes for a certain amount of convenience in connection with other constraints that might be needed
it's usual... to single out one key as the primary key (and any other keys for the relvar in question are then said to be alternate keys). But whether some key is to be chosen as primary, and if so which one, are essentially psychological issues, beyond the purview of the relational model as such. As a matter of good practice, most base relvars probably should have a primary key—but, to repeat, this rule, if it is a rule, really isn't a relational issue as such... Strong recommendation [to SQL users]: For base tables, at any rate, use PRIMARY KEY and/or UNIQUE specifications to ensure that every such table does have at least one key.
SQL and Relational Theory: How to Write Accurate SQL Code By C. J. Date
In standard SQL PRIMARY KEY
- implies uniqueness but you can specify that explicitly (using
UNIQUE
). - implies
NOT NULL
but you can specify that explicitly when creating columns (but you should be avoiding nulls anyhow!) - allows you to omit its columns in a
FOREIGN KEY
but you can specify them explicitly. - can be declared for only one key per table but it is not clear why (Codd, who originally proposed the concept, did not impose such a restriction).
In some products PRIMARY KEY
implies the table's clustered index but you can specify that explicitly (you may not want the primary key to be the clustered index!)
For some people PRIMARY KEY
has purely psychological significance:
- they think it signifies that the key will be referenced in a foreign key (this was proposed by Codd but not actually adopted by standard SQL nor SQL vendors).
- they think it signifies the sole key of the table (but the failure to enforce other candidate keys leads to loss of data integrity).
- they think it implies a 'surrogate' or 'artificial ' key with no significance to the business (but actually imposes unwanted significance on the enterprise by being exposed to users).

- 55,269
- 12
- 100
- 138
-
you can have 1 NULL value in UNIQUE column if not definied as NOT NULL, but you can' have any NULLS in PRIMARY KEY column/s – mr R Mar 15 '17 at 18:09
Every primary key is a unique constraint, but in addition to the PK, a table can have additional unique constraints.
Say you have a table Employees, PK EmployeeID. You can add a unique constraint on SSN, for example.

- 9,531
- 1
- 24
- 43
Unique Key constraints:
- Unique key constraint will provide you a constraint like the column values should retain uniqueness.
- It will create non-clustered index by default
- Any number of unique constraints can be added to a table.
It will allow null value in the column.
ALTER TABLE table_name ADD CONSTRAINT UNIQUE_CONSTRAINT UNIQUE (column_name1, column_name2, ...)
Primary Key:
- Primary key will create column data uniqueness in the table.
- Primary key will create clustered index by default
- Only one Primay key can be created for a table
- Multiple columns can be consolidated to form a single primary key
It wont allow null values.
ALTER TABLE table_name ADD CONSTRAINT KEY_CONSTRAINT PRIMARY KEY (column_name)

- 81
- 1
- 5
-
Primary key point 4: A `UNIQUE` constraint can be either a simple key or a compound key (simple = one column, compound = multiple columns) i.e. no different from `PRIMARY KEY` in this respect. – onedaywhen Feb 22 '12 at 08:43
In addition to Andrew's answer, you can only have one primary key per table but you can have many unique constraints.

- 20,908
- 5
- 52
- 76
-
1
-
12Technically you can have a primary key composed of multiple fields, but you can still only have one overall primary key. – MattC Aug 20 '09 at 20:31
- Primary key's purpose is to uniquely identify a row in a table. Unique constraint ensures that a field's value is unique among the rows in table.
- You can have only one primary key per table. You can have more than one unique constraint per table.

- 14,123
- 2
- 39
- 62
A primary key is a minimal set of columns such that any two records with identical values in those columns have identical values in all columns. Note that a primary key can consist of multiple columns.
A uniqueness constraint is exactly what it sounds like.

- 13,916
- 6
- 45
- 91
-
1@Thom your wording makes it sound like a uniqueness constraint can only apply to a single column, which is not true. – Kip Aug 20 '09 at 20:30
The UNIQUE constraint uniquely identifies each record in a database table.
The UNIQUE and PRIMARY KEY constraints both provide a guarantee for uniqueness for a column or set of columns.
A PRIMARY KEY constraint automatically has a UNIQUE constraint defined on it.
Note that you can have many UNIQUE constraints per table, but only one PRIMARY KEY constraint per table

- 2,975
- 1
- 10
- 20
Primary key can't be null but unique constraint is nullable. when you choose a primary key for your table it's atomatically Index that field.

- 7,115
- 18
- 83
- 125
Primary keys are essentially combination of (unique +not null). also when referencing a foreign key the rdbms requires Primary key.
Unique key just imposes uniqueness of the column.A value of field can be NULL in case of uniqe key. Also it cannot be used to reference a foreign key, that is quite obvious as u can have null values in it

- 5,659
- 16
- 56
- 69
-
1No, a foreign key can reference columns in a unique constraint, too. – Bill Karwin Aug 20 '09 at 20:45
There are several good answers in here so far. In addition to the fact that a primary key can't be null, is a unique constraint itself, and can be comprised of multiple columns, there are deeper meanings that depend on the database server you are using.
I am a SQL Server user, so a primary key has a more specific meaning to me. In SQL Server, by default, primary keys are also part of what is called the "clustered index". A clustered index defines the actual ordering of data pages for that particular table, which means that the primary key ordering matches the physical order of rows on disk.
I know that one, possibly more, of MySql's table formats also support clustered indexing, which means the same thing as it does in SQL Server...it defines the physical row ordering on disk.
Oracle provides something called Index Organized Tables, which order the rows on disk by the primary key.
I am not very familiar with DB2, however I think a clustered index means the rows on disk are stored in the same order as a separate index. I don't know if the clustered index must match the primary key, or if it can be a distinct index.

- 32,447
- 15
- 90
- 130
-
Oracle has Index Organized Tables, which are like SQL Server clustered index, except that the ordering is on the primary key, where as SQL Server have its clustered index on some other index. – Shannon Severance Aug 20 '09 at 21:22
-
@Shannon: In SQL Server, the clustered index IS the set of physical pages on disk, just like an Oracle Index-Organized table. There is no separate index for a clustered index...however a clustered index in SQL Server does not have to be the primary key index. Tables are created to cluster on the primary key by default, but are not restricted to being clustered by primary key. – jrista Aug 20 '09 at 21:59
Both guarantee uniqueness across the rows in the table, with the exception of nulls as mentioned in some of the other answers.
Additionally, a primary key "comes with" an index, which could be either clustered or non-clustered.

- 66
- 3
-
Many RDBMSes will automatically create indexes for unique constraints. (I do not know of any that don't.) – Shannon Severance Aug 20 '09 at 21:23
A great number of the answers here have discussed the properties of PK vs unique constraints. But it is more important to understand the difference in concept.
A primary key is considered to be an identifier of the record in the database. So these will for example be referenced when creating foreign key references between tables. A primary key should therefore under normal circumstances never contain values that have any meaining in your domain (often automatically incremential fields are used for this).
A unique constraint is just a way of enforcing domain specific business rules in your database schema.
Becuase a PK it is an identifier for the record, you can never change the value of a primary key.

- 12,206
- 8
- 54
- 70
-
2+1 It's good to look at this aspect too. However your last sentence is not quite true: `Becuase a PK it is an identifier for the record, you can never change the value of a primary key.` You probably *shouldn't* change the primary key, but you *can* do it. – Mark Byers May 26 '10 at 20:48
-
-1 "A primary key should therefore under normal circumstances never contain values that have any meaining in your domain" -- a matter of taste presented as fact. – onedaywhen Feb 22 '12 at 08:38