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

Question

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

Я прочитал много статей / дискуссий / сообщений в группах новостей, в которых говорится, что вместо PK лучше использовать уникальное ограничение (он же уникальный индекс для некоторой базы данных).

Какова ваша точка зрения?

Answer 1

Я обычно использую как PK, так и UNIQUE KEY. Потому что даже если вы не обозначаете PK в своей схеме, он всегда создается для вас внутри. Это верно как для SQL Server 2005, так и для MySQL 5.

Но я не использую столбец PK в моих SQL. Это для целей управления, таких как УДАЛЕНИЕ некоторых ошибочных строк, обнаружение пробелов между значениями PK, если установлено значение AUTO INCREMENT. И имеет смысл иметь в качестве чисел PK, а не набор столбцов или массивов символов.

Answer 2

сообщений о том, что вместо PK

лучше использовать уникальное ограничение (он же уникальный индекс для некоторых дБ)

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

перевод:

сообщений о том, что лучше использовать естественный ключ вместо суррогатного ключа

Answer 3

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

ЛИЧНО, я использую GUID или автоинкрементный BIGINTS (Identity Insert для SQL SERVER) для уникальных ключей, используемых для перекрестных ссылок между моими таблицами. Затем я буду использовать другие данные, чтобы позволить пользователю выбирать конкретные записи.

Например, у меня будет список сотрудников, и ко всем записям, которые я использую за кулисами, будет прикреплен GUID, но когда пользователь выбирает сотрудника, они выбирают его на основе следующих полей: LastName + FirstName + EmployeeNumber.

Мой первичный ключ в этом сценарии - LastName + FirstName + EmployeeNumber, а уникальный ключ - связанный GUID.

Answer 4

Я думал об этой проблеме сам. Если вы используете уникальный, вы повредите 2. NF. В соответствии с этим каждый не-pk-атрибут должен зависеть от PK. Пара атрибутов в этом уникальном ограничении должна рассматриваться как часть PK.

извините за ответ на этот вопрос 7 лет спустя, но не хотел начинать новое обсуждение.

Answer 5

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

Отредактировано, чтобы добавить: Это также реальная проблема, что данные реального мира часто не имеют естественного ключа, который действительно гарантирует уникальность в нормализованной структуре таблиц, особенно если база данных ориентирована на людей. Имена, даже имя, адрес и номер телефона вместе (думаю, отец и сын в одной медицинской практике) не обязательно являются уникальными.

Answer 6

Если вы планируете использовать LINQ-to-SQL, вашим таблицам потребуются первичные ключи, если вы планируете выполнять обновления, и им потребуется столбец timestamp, если вы планируете работать в автономной среде (например, передавать объект через приложение службы WCF).

Если вам нравится .NET, PK и FK - ваши друзья.