Должны ли внешние ключи становиться первичным ключом таблицы?

У меня есть таблица (session_comments) со следующей структурой полей:

student_id (foreign key to students table)
session_id (foreign key to sessions table)
session_subject_ID (foreign key to session_subjects table)
user_id (foreign key to users table)
comment_date_time
comment

Теперь комбинация student_id, session_id и session_subject_id однозначно идентифицирует комментарий об этом ученике для этого предмета сеанса.

Учитывая, что в совокупности они уникальны, хотя они являются внешними ключами, есть ли у меня преимущество в том, что они делают для них объединенный первичный ключ для этой таблицы?

Еще раз спасибо.

Ответ 1

Создание первичного ключа приведет к уникальности (в отличие от него).
Первичный ключ предположительно будет кластеризован (в зависимости от dbms), что улучшит производительность для некоторых запросов.
Сохраняет пространство для добавления уникального ограничения, которое в некоторых СУБД также создает уникальный индекс.

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

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

Если вы обсуждаете, создавать ли суррогатный первичный ключ + уникальное ограничение для трех столбцов, я бы сказал, что это зависит от того, будут ли в этой таблице иметь дочерние таблицы. Если это произойдет, то ссылка на суррогатный ключ будет проще и меньше. Если этого не произойдет, то ИМО, суррогатный ключ на самом деле не даст вам многого, и вы могли бы также использовать три столбца в качестве ПК.

Ответ 2

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

Ответ 3

Обсуждение естественных и искусственных ключей так же стара, как и любая реализация базы данных. Читайте о pro и con на wikipedia.

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

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

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

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

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

Если вы серьезно относитесь к этим проблемам, и если вы пытаетесь создать сложную систему, прочитайте хорошую литературу (CJDate Введение в базу данных Системы, в настоящее время в восьмом издании, приходят на ум)

Ответ 4

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

Уникальные идентификаторы для postgres: http://www.postgresql.org/docs/8.1/interactive/datatype.html#DATATYPE-SERIAL

Уникальные идентификаторы для Mysql: http://dev.mysql.com/doc/refman/5.0/en/example-auto-increment.html

Ответ 5

Единственная причина сделать их составным первичным ключом - обеспечить соблюдение одного комментария для учащегося/сессии/темы. Предполагая, что вы не хотите этого делать, я бы не создал еще один ключ.

Ответ 6

Нет. FOREIGN ключи могут содержать NULL, которые не разрешены в ключах PRIMARY. Лучшее, что вы можете сделать, это создать индекс UNIQUE из столбцов.

Создайте в таблице PRIMARY.

Ответ: Мой следующий вопрос: Есть ли возможность перекрытия между ключами из 4 таблиц?

Эти два будут создавать тот же составной ключ 101010101: студент: 1010, сеанс: 10, тема: 10, пользователь: 1 студент: 10, сеанс: 1010, тема: 10, пользователь: 1

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

Вероятно, лучше всего пойти с истинным первичным ключом.