views:

215

answers:

5

I tried to find it out in google but not satisfactory answer is given out there.Can anybody explain the solid difference.
actually if Primary key is used to select data uniquely then what is the need of Unique key?
when should I use a Primary key and when to use a Unique key?

+3  A: 

A primary key does not allow nulls, a unique key will allow one null (on sql server and multiple nulls on Oracle) A table can only have one primary key but many unique keys

use primary keys when you want to set up foreign key relationships

Here is a small example with just one column in each table

--primary key table
CREATE TABLE PrimaryTest (id INT PRIMARY KEY NOT NULL)
GO

-- foreign key table
CREATE TABLE ForeignTest (Pkid INT NOT NULL)
GO


--relationship
ALTER TABLE dbo.ForeignTest ADD CONSTRAINT
    FK_ForeignTest_PrimaryTest FOREIGN KEY
    (
    Pkid
    ) REFERENCES dbo.PrimaryTest
    (
    id
    ) ON UPDATE  NO ACTION 
     ON DELETE  NO ACTION 

GO

insert a row in the primary key table

insert PrimaryTest values(1)

insert a row in the foreign key table with a value that exist in the primary key table

insert ForeignTest values(1)

Now this will fail because value 2 does not exist in the primary key table

insert ForeignTest values(2)

Msg 547, Level 16, State 0, Line 1 The INSERT statement conflicted with the FOREIGN KEY constraint "FK_ForeignTest_PrimaryTest". The conflict occurred in database "aspnetdb", table "dbo.PrimaryTest", column 'id'. The statement has been terminated.

SQLMenace
can you give a small example how can I use unique key to set up foreign key relationships
nectar
@SQLMen this example is all about foreign keys I was asking about unique keys.
nectar
+2  A: 

A primary key is a unique key. Both types of key serve to uniquely identify a single row in a table. Many RDBMSs require that one of the unique keys on a table be designated as the "primary key", for several different implementation reasons. In terms of data integrity, there is no difference.

Christian Hayter
a unique key will allow at least one null where a PK won't
SQLMenace
@SQLMenace, Not in the relational model. In relational terms all keys are equal. SQL unique constraints can be created on nullable columns, but that's different. A column that contains a null certainly isn't a key in the proper relational sense.
dportas
+1  A: 

Primary Key and Unique Key are used for different things - understanding what they are for will help you decide when to use them.

The primary key is used to identify a row of data in a table. It is used whenever you need to refer to a particular row, eg. in other tables or by application code etc. In order to identify a row, the values of a PK must be unique. Furthermore, they can't be null, because most dbms treat null as not equal to null (since null typically means "unknown"). A table can have only have one PK. All tables in your databse should have a PK (although this is not enforced by most dbms). PK can span multiple columns.

Unique key constraints are used to ensure that data is not duplicated in two rows in the database. One row in the database is allowed to have null for the value of the unique key constraint. Although a table should have a PK, it need not have any additional unique keys. However, tables can have more than one unique key if that meets your needs. Like PKs, unique keys can span multiple columns.

It is also worth knowing that, by default, many dbms index and physically order tables on disk using the PK. This means that looking up values by their PK is faster than using other values in a row. Typically, however, you can override this behaviour if required.

Kramii
what do you mean by `PK can span multiple columns.`?
nectar
In many examples, you see the Primary Key is a single column in the table; often an integer id number that uniquely identifies the row (this is called an identity column). That's fine (and often convenient), but the PK doesn't *have* to be a single column.
Kramii
For example, you could have a table of Products. Say each product comes in several models and several colours, so the Products table has a ModelNum column and a Colour column. Now, neither ModelNum nor Colour column uniquely identifies a Product, but together, they do. In that case, you can define a Primary Key that includes both the ModelNum and Colour columns (this is called a "composite primary key"). Of course, there are pros and cons of the identity column PK vs the composite column PK approach... but that is another question.
Kramii
+1  A: 

The term "unique key" is both ambiguous and tautologous. In the relational model, a "key" means a candidate key, which by definition is unique anyway. A primary key is just any one of the candidate keys of a relation. Therefore "unique key" means exactly the same as "candidate key" which means exactly the same as "primary key". There is no difference.

However, SQL has something called a UNIQUE constraint which is subtly different to a SQL PRIMARY KEY constraint - both enforce uniqueness but PRIMARY KEY can only be used once per table. UNIQUE constraints also allow nulls whereas PRIMARY KEY constraints don't.

So the potentially confusing term "unique key" is most often used to mean a key enforced by a UNIQUE constraint. It might even be used to mean a UNIQUE constraint on nullable columns, although that's a very dubious use of the term in my opinion because a set of columns that include nulls cannot be a candidate key so the use of the word "key" for nullable columns isn't really correct and is bound to cause confusion.

dportas
A: 

Just to add another example:

Think of a table holding user data, where each user has an email address. No two users can have the same email address, so that column becomes a unique key. While it could be the primary key (I have never made a string a primary key), it doesn't have to be.

Quenton Jones