При каких условиях нам нужно использовать составные ключи в базе данных

Question

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

Как люди и Книги

person_id and book_id will make the primary key.

Но я хочуспросить, что нам нужно жестко кодировать этот язык программирования

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

id,person_id ,book_id

Answer 1

Составные ключи никогда не должны учитываться в «новых» приложениях.Они использовались в прошлом людьми, которые думали, что «бизнес-ключи» лучше, чем «суррогатные ключи».

Редактировать: По просьбе Криса я расширяю свой ответ.

Позвольте мне начать с того, что я понимаю этот вопрос как «Составные первичные ключи» против «Суррогатные ключи».

Кроме того, я допускаю, что существует один вариант использования, в котором имеет смысл составной ключ: в таблицах перекрестных ссылок, также называемых "таблицами ссылок".Они используются в таблицах «многие ко многим» и состоят только из двух полей, причем оба внешних ключа образуют первичный ключ для таблицы внешних ссылок.Например, таблица UserRole будет содержать user_id и role_id, больше ничего.Например, в Java нет представления классов для такой таблицы.Обычно это @ManyToMany, с Collection с обеих сторон.

Я поделился своими взглядами на естественные ключи и суррогатные ключи в другом ответе ( Hibernate: мнения в Composite PK против суррогатных PK ), и я считаю, что у составных ключей есть некоторые недостаткиЕстественный ключ, не приносящий никакой реальной пользы.

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

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

Составные ключи в основном используются для того, чтобы записи в таблице были уникальными на основе набора столбцов.Например, если у вас есть таблица Customers, у вас может быть NationalId + Country в качестве уникального значения, что означает, что два пользователя не могут использовать один и тот же SSN, если их страна - США.Но можно иметь один и тот же номер для двух записей, если они не находятся в одной стране.Если вам нравятся составные ключи, это будет хорошим кандидатом на это.Но, как я уже говорил, вы можете использовать суррогатный ключ и применить ограничение unique.Вы получите преимущества составного ключа плюс безопасность суррогатного ключа.

Answer 2

Я не могу придумать условия, при которых НЕОБХОДИМО использовать составной ключ. Вот некоторые аргументы Pro , использующие один столбец идентификатора:
1. лучше индексирование
2. более простые соединения
3. проще дизайн ГИС
4. тот факт, что большинство ORM лучше работают с однополевыми PK (к сожалению)
5. проще удалять записи

В вашем случае, хотя вы можете иметь составной / суррогатный ключ на person_id и book_id, и это будет очень полезно, вы также можете иметь один столбец идентификатора, который CAN будет вашим основным ключом также, но это не должно быть. Вы можете использовать person_id и book_id в качестве PK или просто индекс, и то же самое для столбцов id. Столбец id облегчает вашу жизнь при удалении материала или выборе отдельных столбцов для просмотра. В современных СУБД, где вам обычно не нужно беспокоиться о размере таблицы, рекомендуется включать один столбец - предпочтительно автоматически увеличивать столбцы идентификаторов для всех ваших таблиц на всякий случай, если это необходимо. Я верю, что это не повредит вам.

Answer 3

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

Оставляя это в стороне на данный момент, ваш пример демонстрирует, зачем нужны составные ключи - более чем у одного человека может быть копия конкретной книги - и у человека может быть несколько книг - это отношения N: M. И представить это в реляционной базе данных очень просто: вы помещаете в середину другую таблицу с PK книги и PK человека.

id, person_id, book_id

Но (если вы не хотите учитывать сценарий, в котором вам нужно разграничить 2 копии одной и той же книги, принадлежащей одному и тому же человеку, и в этом случае схема требует нескольких других изменений), поскольку комбинация person_id и book_id уже уникальна зачем вам нужен другой уникальный идентификатор, который не имеет отношения к данным, которые вы пытаетесь смоделировать.

Answer 4

Если вы храните отношения между человеком и книгами, которые являются однозначными (например, возможно, у вас есть веб-сайт, где пользователи могут оценивать прочитанные книги по шкале от 1 до 5), тогдасоставной первичный ключ в таблице votes для person_id и book_id имеет такой же смысл, если не больше, как наличие сгенерированного идентификатора и уникального индекса для комбинации (person_id, book_id).Сочетание человека и книги определяет протокол голосования.