Difference between Unique Key and Primary Keys

后端 未结 5 809
小鲜肉
小鲜肉 2020-12-16 17:44

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\         


        
相关标签:
5条回答
  • 2020-12-16 18:00

    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.

    0 讨论(0)
  • 2020-12-16 18:00

    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

    0 讨论(0)
  • 2020-12-16 18:07

    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.

    0 讨论(0)
  • 2020-12-16 18:13

    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
    );
    
    0 讨论(0)
  • 2020-12-16 18:15

    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.

    0 讨论(0)
提交回复
热议问题