Первичный ключ или Уникальный индекс?

Я почти никогда не составляю таблицу без числового первичного ключа. Если существует также естественный ключ, который должен быть уникальным, я также поместил уникальный индекс на него. Соединения быстрее на целых числах, чем многостолбцовые естественные ключи, данные только должны измениться в одном месте (естественные ключи имеют тенденцию должны быть обновлены, который является плохой вещью, когда это находится в первичном ключе - отношения внешнего ключа). Если Вы испытываете необходимость в использовании репликации GUID вместо целого числа, но по большей части я предпочитаю ключ, который является пользователем, читаемым особенно, если они должны видеть его для различения John Smith и John Smith.

Несколько раз я не создаю суррогатный ключ, когда у меня есть присоединяющаяся таблица, которая вовлечена в many-many отношения. В этом случае я объявляю оба поля как первичный ключ.

В дополнение к тому, что сказали другие ответы, некоторый май баз данных и систем требует основное устройство присутствовать. Одна ситуация приходит на ум; при использовании репликации предприятия с Informix должен присутствовать PK, чтобы таблица участвовала в репликации.

Пока Вы не позволяете ПУСТОЙ УКАЗАТЕЛЬ для значения, они должны быть обработаны, то же, но ПУСТОЙ УКАЗАТЕЛЬ значения обрабатывается по-другому на базах данных (MS-SQL AFAIK не позволяют больше чем одно (1) Нулевое значение, MySQL и Oracle позволяют это, если столбец УНИКАЛЕН), Таким образом, Вы должны определять этот столбец NOT NULL UNIQUE INDEX

Если что-то - первичный ключ, в зависимости от Вашего механизма DB, вся таблица отсортирована по первичному ключу. Это означает, что поиски намного быстрее на первичном ключе, потому что он не должен делать никакого разыменования, поскольку он имеет отношение к любому другому виду индекса. Помимо этого, это - просто теория.

Нет никаких недостатков первичных ключей.

Для добавления просто некоторой информации к @MrWiggles и @Peter ответам Parker когда таблица не имеет первичного ключа, например, Вы не сможете отредактировать данные в некоторых приложениях (они закончат тем, что говорили, что sth нравится, не может отредактировать / удаляют данные без первичного ключа). Postgresql позволяет нескольким Нулевым значениям быть в столбце UNIQUE, PRIMARY KEY не позволяет, АННУЛИРУЕТ. Также некоторые ORM, которые генерируют код, могут иметь некоторые проблемы с таблицами без первичных ключей.

ОБНОВЛЕНИЕ:

Насколько я знаю, не возможно копировать таблицы без первичных ключей в MSSQL, по крайней мере, без проблем ( детали ).

Выбор того, когда использовать суррогатный первичный ключ в противоположность естественному ключу, хитер. Ответы такой как, всегда или никогда, редко полезны. Я нахожу, что это зависит от ситуации.

Как пример, у меня есть следующие таблицы:

CREATE TABLE toll_booths (
    id            INTEGER       NOT NULL PRIMARY KEY,
    name          VARCHAR(255)  NOT NULL,
    ...
    UNIQUE(name)
)

CREATE TABLE cars (
    vin           VARCHAR(17)   NOT NULL PRIMARY KEY,
    license_plate VARCHAR(10)   NOT NULL,
    ...
    UNIQUE(license_plate)
)

CREATE TABLE drive_through (
    id            INTEGER       NOT NULL PRIMARY KEY,
    toll_booth_id INTEGER       NOT NULL REFERENCES toll_booths(id),
    vin           VARCHAR(17)   NOT NULL REFERENCES cars(vin),
    at            TIMESTAMP     DEFAULT CURRENT_TIMESTAMP NOT NULL,
    amount        NUMERIC(10,4) NOT NULL,
    ...
    UNIQUE(toll_booth_id, vin)
)

у Нас есть две таблицы объекта (toll_booths и cars) и таблица транзакций (drive_through). toll_booth таблица использует суррогатный ключ, потому что она не имеет никакого естественного атрибута, который, как гарантируют, не изменится (имя может легко измениться). cars таблица использует естественный первичный ключ, потому что она имеет не изменяющийся уникальный идентификатор (vin). drive_through таблица транзакций использует суррогатный ключ для легкой идентификации, но также и имеет ограничение на уникальность данных на атрибуты, которые, как гарантируют, будут уникальны в то время, когда запись вставляется.

http://database-programmer.blogspot.com имеет некоторые большие статьи об этом конкретном предмете.

Внешние ключи работают с ограничениями на уникальность данных, а также первичными ключами. Из Книг Онлайн:

ограничение FOREIGN KEY А не должно быть связано только с ограничением PRIMARY KEY в другой таблице; это может также быть определено для ссылки на столбцы ограничения UNIQUE в другой таблице

Для репликации транзакций, Вам нужен первичный ключ. Из Книг Онлайн:

Таблицы, опубликованные для репликации транзакций, должны иметь первичный ключ. Если таблица находится в публикации репликации транзакций, Вы не можете отключить индексы, которые связаны со столбцами первичного ключа. Эти индексы требуются репликацией. Для отключения индекса необходимо сначала отбросить таблицу из публикации.

Оба ответа являются для SQL Server 2005.

Вы видите его как это:

Первичный ключ А Уникален

А, Уникальным значением не должен быть Representaion Элемента

Значение?; Хорошо первичный ключ используется для идентификации элемента, если бы у Вас есть "Человек", требуется иметь Персональный идентификационный номер (SSN или такой), который является Основным Личности.

, С другой стороны, у человека могло бы быть электронное письмо, которое уникально, но doensn't идентифицируют человека.

у меня всегда есть Первичные ключи, даже в таблицах отношений (середина таблицы / таблица соединений), у меня могли бы быть они. Почему? Хорошо мне нравится следовать стандарту при кодировании, если у "Человека" есть идентификатор, Автомобиль имеет идентификатор, ну, в общем, затем Человек->, Автомобиль должен иметь идентификатор также!

Нет такой вещи как первичный ключ в реляционной теории данных, таким образом, на Ваш вопрос нужно ответить на практическом уровне.

Уникальные индексы не являются частью стандарта SQL. Конкретная реализация DBMS определит то, что является последствиями объявления уникального индекса.

В Oracle, объявляя первичный ключ приведет к уникальному индексу, создаваемому от Вашего имени, таким образом, вопрос почти спорен. Я не могу сказать Вам о других продуктах DBMS.

я одобряю объявление первичного ключа. Это имеет эффект запрещения, АННУЛИРУЕТ в столбце (столбцах) ключа, а также запрещающих дубликатах. Я также одобряю объявление, что ССЫЛОЧНЫЕ ограничения осуществляют объектную целостность. Во многих случаях объявление индекса на столбце (столбцах) внешнего ключа ускорит соединения. Этот вид индекса не должен в целом быть уникальным.

Что такое уникальный индекс?

Уникальный индекс на столбце - это индекс на этом столбце, который также обеспечивает ограничение, что вы не можете иметь два одинаковых значения в этом столбце в двух разных строках. Пример:

CREATE TABLE table1 (foo int, bar int);
CREATE UNIQUE INDEX ux_table1_foo ON table1(foo);  -- Create unique index on foo.

INSERT INTO table1 (foo, bar) VALUES (1, 2); -- OK
INSERT INTO table1 (foo, bar) VALUES (2, 2); -- OK
INSERT INTO table1 (foo, bar) VALUES (3, 1); -- OK
INSERT INTO table1 (foo, bar) VALUES (1, 4); -- Fails!

Duplicate entry '1' for key 'ux_table1_foo'

Последняя вставка не удалась, потому что она нарушает уникальный индекс на столбце foo, когда пытается вставить значение 1 в этот столбец во второй раз.

В MySQL уникальное ограничение допускает несколько NULL.

Можно создать уникальный индекс для нескольких столбцов.

Первичный ключ против уникального индекса

Одинаковые вещи:

• Первичный ключ подразумевает уникальный индекс.

Вещи, которые отличаются:

• Первичный ключ также подразумевает NOT NULL, но уникальный индекс может быть нулевым.
• Первичный ключ может быть только один, но уникальных индексов может быть несколько.
• Если не определен кластеризованный индекс, то первичный ключ будет кластеризованным индексом.