CODEWITHSUNDEEP
mysqlsql
locoboy
locoboy

Reputation: 38960

Difference between Unique Key and Primary Keys

I came across the following SQL in a book:

CREATE TABLE 'categories'(
id SMALLINT NOT NULL AUTO INCREMENT,
category VARCHAR(30) NOT NULL,
PRIMARY KEY('id'),
UNIQUE KEY 'category'('category')
)ENGINE=MyISAM DEFAULT CHARSET = utf8;

I was wondering is there a reason why I would need a PRIMARY and UNIQUE KEY in the same table? I guess, underlying that question is, what is the difference between PRIMARY and UNIQUE keys?

Upvotes: 12

Views: 15063

Answers (5)

Brahmareddy K
Brahmareddy K

Reputation: 614

A UNIQUE constraint and PRIMARY key both are similar and it provide unique enforce uniqueness of the column on which they are defined. Some are basic differences between Primary Key and Unique key are as follows.

Primary key

Primary key cannot have a NULL value. Each table can have only single primary key. Primary key is implemented as indexes on the table. By default this index is clustered index. Primary key can be related with another table's as a Foreign Key. We can generate ID automatically with the help of Auto Increment field. Primary key supports Auto Increment value.

Unique Constraint

Unique Constraint may have a NULL value. Each table can have more than one Unique Constraint. Unique Constraint is also implemented as indexes on the table. By default this index is Non-clustered index. Unique Constraint cannot be related with another table's as a Foreign Key. Unique Constraint doesn't support Auto Increment value.

You can find detailed information from: http://www.oracleinformation.com/2014/04/difference-between-primary-key-and-unique-key.html

Upvotes: 1

Ja͢ck
Ja͢ck

Reputation: 173662

Similarity

Both a PRIMARY and UNIQUE index create a constraint that requires all values to be distinct (1).

Difference

The PRIMARY key (implicitly) defines all key columns as NOT NULL; additionally, a table can only have one primary key.

(1) Each NULL value is considered to be distinct.

Upvotes: 4

Mike Sherrill 'Cat Recall'
Mike Sherrill 'Cat Recall'

Reputation: 95761

The relational model says there's no essential difference between one key and another. That is, when a relation has more than one candidate key, there are no theoretical reasons for declaring that this key is more important than that key. Essentially, that means there's no theoretical reason for identifying one key as a primary key, and all the others as secondary keys. (There might be practical reasons, though.)

Many relations have more than one candidate key. For example, a relation of US states might have data like this.

State      Abbr      Postal Code
--
Alabama    Ala.      AL
Alaska     Alaska    AK
Arizona    Ariz.     AZ
...
Wyoming    Wyo.      WY

It's clear that values in each of those three columns are unique--there are three candidate keys.

If you were going to build a table in SQL to store those values, you might do it like this.

CREATE TABLE states (
  state varchar(15) primary key,
  abbr varchar(10) not null unique,
  postal_code char(2) not null unique
);

And you'd do something like that because SQL doesn't have any other way to say "My table has three separate candidate keys."

I didn't have any particular reason for choosing "state" as the primary key. I could have just as easily chosen "abbr" or "postal_code". Any of those three columns can be used as the target for a foreign key reference, too.

And as far as that goes, I could have built the table like this, too.

CREATE TABLE states (
  state varchar(15) not null unique,
  abbr varchar(10) not null unique,
  postal_code char(2) not null unique
);

Upvotes: 20

Luc M
Luc M

Reputation: 17334

I'm surprised that nobody mentionned that a primary key can be referenced as foreign key into other tables.

Also an unique constraint allows NULL values.

Upvotes: 8

Thomas
Thomas

Reputation: 64674

The reason you need two uniqueness restrictions (one being the Primary Key) is that you are using Id as a surrogate key. I.e., it is an arbitrary value that has no meaning in relation to the data itself. Without the unique key (or colloquially known as "business key" i.e, a key that the user would recognize as being enforced), a user could add two identical category values with different arbitrary Id values. Since users should never see the surrogate key, they would not know why they are seeing a duplicate even though the database would think they are different.

When using surrogate keys, having another unique constraint on something other than the surrogate key is critical to avoid duplicate data.

Depending on who you talk to and how they read the specification, Unique keys( which is redundant by the way. A "key" is by definition unique) are also not supposed to allow nulls. However, one can also read the specifications as saying that Unique constraints, unlike Primary Key constraints, are in fact supposed to allow nulls (how many nulls are allowed also varies by vendor). Most products, including MySQL, do allow nulls in Unique constraints whereas Primary Key constraints do not.

Upvotes: 4

Related Questions