-2

I want to know if it is possible to create more than one primary key in standard SQL. I mean something like that:

CREATE TABLE(Surname CHAR(100) PRIMARY KEY, Name CHAR(100) PRIMARY KEY)

Is that legal in SQL? If not, please link me a reference to the standard that says that is not possible...

  • You can have only one primary key, but it can consist of more than one column. Using names as a primary key is legal, but a very bad idea because more than one person can have the same name. – Dan Bracuk Oct 17 '13 at 16:34
  • Possible reference here? http://stackoverflow.com/questions/217945/can-i-have-multiple-primary-keys-in-a-single-table/217952#217952 – Tiny Haitian Oct 17 '13 at 16:34
  • Composite primary key? – Kaf Oct 17 '13 at 16:35

6 Answers6

1

Edit after the question has been clarified.

The definition of a primary key is that there is one and only one. So, no you cannot create two primary keys on two different columm.

You can however create a primary key on one column and a unique constraint on another:

create table person
(
   surname varchar(100) not null primary key,
   name varchar(100) not null,
   constraint only_one_name unique (name)
);

The above is standard SQL for all I know.

Here is a link to the book "SQL-99, Complete" which re-states the SQL standard in a more pragmatic way: https://mariadb.com/kb/en/constraint_type-primary-key-constraint/

Quote from the book:

A Base table may be constrained by no more than one PRIMARY KEY Constraint

The original wording from the SQL standard (which is not free, so no one can give you a link to that):

A <table definition> shall specify at most one implicit or explicit <unique constraint definition> that specifies PRIMARY KEY.

(Emphasis mine)


Note that you almost never want char - especially not with a length greater than just two or three characters. The CHAR datatype pads all values to the defined length. So if you inserted the value 'FOO' into a CHAR(10) column it will (has to) be stored as 'FOO '

  • 1
    I want to know if the "standard" permits to define two different columns as primary key... – MasterChief Oct 17 '13 at 16:38
  • @MasterChief: the above does create a primary key with two columns - and it is standard SQL. What exactly is your question? –  Oct 17 '13 at 16:38
  • 1
    @a_horse_with_no_name My intention is to ask if i can define two *different* primary key in a table (not a primary key defined on two columns...) – MasterChief Oct 17 '13 at 16:41
  • 2
    @MasterChief: then the answer is a clear NO. By definition a table can only have a **single** primary key. –  Oct 17 '13 at 16:42
0

No, It's not legal to create two primary keys in SQL, If you are able to create two separate primary keys then it's not a primary key anymore.

You can create a composite primary keys, like primary key(surname, name) for e.g. but this will be never applicable not good pratice, primary key on name and surname.

Vishwanath Dalvi
  • 35,388
  • 41
  • 123
  • 155
  • 1
    To be clear, a primary key on _names_ is not good practice; composite primary keys _in general_ are perfectly valid. – D Stanley Oct 17 '13 at 16:36
0

No - but you can have a single primary key that is a combination of multiple columns:

From MSDN:

A table typically has a column or combination of columns that contain values that uniquely identify each row in the table. This column, or columns, is called the primary key (PK) of the table and enforces the entity integrity of the table. You can create a primary key by defining a PRIMARY KEY constraint when you create or modify a table.

A table can have only one PRIMARY KEY constraint, and a column that participates in the PRIMARY KEY constraint cannot accept null values. Because PRIMARY KEY constraints guarantee unique data, they are frequently defined on an identity column.

Community
  • 1
  • 1
D Stanley
  • 149,601
  • 11
  • 178
  • 240
  • 1
    Can you link me an official document that said that? – MasterChief Oct 17 '13 at 16:36
  • MasterChief is asking about standard SQL, not T-SQL (the tag `sql` denotes questions related to standard SQL, not for MS SQL Server) –  Oct 17 '13 at 16:36
  • @MasterChief There are many SQL standards - which one are you interested in? – D Stanley Oct 17 '13 at 16:49
  • @DStanley: There is only one SQL *standard*. There are many SQL *dialects* though (roughly as many as there are SQL based DBMS) –  Oct 17 '13 at 16:51
  • [The SQL standard has gone through a number of revisions:](http://en.wikipedia.org/wiki/SQL#Standardization) – D Stanley Oct 17 '13 at 16:53
0

This is a bit pedantic, but of course you cannot create more than one primary key, just like there cannot be more than one tallest person in the room. But you can, (and many times should), create more than one unique key. and, except for one minor distinction there is no functional difference between them. A unique key can be used as the target of a FK constraint, or in joins just like a primary key can.

Charles Bretana
  • 143,358
  • 22
  • 150
  • 216
0

you can only have one primary key, but this primary key can be made by N columns.

example:

create table "TABLE NAME"(
    "Surname" CHAR(100),
    "Name" CHAR(100),
    primary key ("Surname", "Name")
);
0

You can have a primary key containing multiple columns. This is often done in attributive tables, where one part of the key contains the id of the record in the table you're attributing to.

You can't have more than one primary key simply because it is ranked as 'the most important'. There can't be two things 'most important'.

venite
  • 303
  • 4
  • 13
  • Most important? I thought the purpose of a primary key was to make the record unique so you could use it to identify the records you want. – Dan Bracuk Oct 17 '13 at 16:45
  • It is not the most important column information-wise. In many cases it will just be a generated number which doesn't add any information to a human. But as you said, it is what makes the record unique, which is why it is the most important column in a relational DB. The primary key should be the column you refer to from related tables in the database (there are reasons not to use the PK, but not many). Because of this, the optimizer usually tries to access the records via the PK. In short, primary key, pretty important. – venite Oct 17 '13 at 16:58