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

Question

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

Я создаю новую базу данных для нового проекта, и у меня возникла дилемма:

В теории БД первичный ключ является фундаментальным элементом, это нормально, но в РЕАЛЬНЫХ проектах каковы преимущества и недостатки обоих?

Что вы используете в проектах?

EDIT: ... а как насчет первичных ключей и репликации на сервере MS SQL?

Answer 1

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

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

Answer 2

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

Answer 3

Если бы это было до меня ...

Вам необходимо удовлетворить требования базы данных и ваших приложений.

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

Затем вы добавите в таблицу хотя бы еще один уникальный индекс для использования вашим приложением. Это может быть индекс для employee_id, account_id, customer_id и т. Д. Если возможно, этот индекс не должен быть составным.

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

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

Это позаботится о требованиях вашего приложения.

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

Answer 4

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

Answer 5

Уникальный индекс может иметь одно значение NULL. Создает НЕКЛАСТЕРНЫЙ ИНДЕКС. Первичный ключ не может содержать значение NULL. Создает КЛАСТЕРНЫЙ ИНДЕКС.