Составной первичный ключ и дополнительный столбец "ID"?

Ответ 1

Скажем, что {Author,Title,Edition} однозначно идентифицирует книгу, тогда выполняется следующее:

• Это (супер) ключ - однозначно идентифицирует кортеж (строку).

• Это неприводимо - удаление любого из столбцов больше не делает его ключом.

• Это ключ-кандидат - неприводимый ключ - это ключ-кандидат.

Теперь рассмотрим идентификатор (целое число)

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

Чтобы сделать эти "другие" таблицы и индексы меньше, я могу добавить столбец unique-integer в таблицу Book, которая будет использоваться в качестве ключа, на который будет ссылаться как внешний ключ. Скажите что-то вроде:

alter table `Book` add `BookID` integer not null identity;

Если BookID является (должно быть) уникальным, таблица Book теперь имеет два ключа-кандидата.

Теперь я могу выбрать BookID в качестве первичного ключа.

alter table Book add constraint pk_Book primary key (BookID);

Однако {Author,Title,Edition} должен оставаться ключом (уникальным), чтобы предотвратить что-то вроде этого:

BookID  Author      Title           Edition
----------------------------------------------- 
  1      C.J.Date  Database Design     1
  2      C.J.Date  Database Design     1

Подводя итог, добавление BookID - и выбор его как основного - не остановил {Author,Title,Edition} как (кандидата). Он все еще должен иметь свое собственное уникальное ограничение и обычно соответствующий индекс.

Также обратите внимание, что с точки зрения дизайна это решение было принято на "физическом уровне". В общем, на логическом уровне дизайна этот ID не существует - он появился во время рассмотрения размеров столбцов и индексов. Таким образом, физическая схема была получена из логической. В зависимости от размера БД, РСУБД и используемого оборудования ни один из этих аргументов по размеру не может иметь измеримого эффекта, поэтому использование {Author,Title,Edition} в качестве ПК может быть совершенно хорошим дизайном - до тех пор, пока не будет доказано по-другому.

Ответ 2

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

Предположим, что вы создали свою Книжную таблицу с Автором как часть первичного ключа.

Предположим, вы узнали примерно через год, что вы ошибочно написали "Рэй Брэдбери". Или, что еще хуже, вы ошиблись "Rachael Bloom". Представьте себе, сколько строк базы данных вам нужно будет изменить для исправления орфографической ошибки. Представьте себе, сколько ссылок на индекс нужно изменить.

Однако, если у вас есть таблица Author с суррогатным ключом, вам нужно исправить только одну строку. Никакие индексы не должны быть изменены.

Наконец, имена таблиц базы данных обычно являются единственными (Книга), а не множественными (Книги).

Ответ 3

Еще одна веская причина для использования суррогатного первичного ключевого сценария заключается в том, что ограничение уникальности должно измениться в будущем (скажем, ISBN необходимо добавить, чтобы сделать книгу уникальной). Повторная передача ваших данных будет намного проще.

Ответ 4

Есть много статей, связанных с этим. Проблемы с составным ключом в вашем случае:

• трудно связать книги с другими объектами
• Жестко редактировать их в сетке, так как большинство сеток не поддерживают составные клавиши (например, kendo grid, jqgrid)
• Вы можете ошибаться Автор, название, издание

Было бы неплохо нормализовать ваши данные и сохранить только идентификатор автора, как (dasblinkenlight). В худшем случае, он/она изменяет свое имя (например, она выходит замуж, и ей нравится ее новое имя).