Внешние ключи должны стать первичным ключом таблицы?
У меня есть таблица (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 однозначно определит комментарий о том студенте для того предмета сессии.
Учитывая, что объединено они уникальны, даже при том, что они - внешние ключи, есть ли преимущество для меня делающий их объединенный первичный ключ для той таблицы?
Еще раз спасибо.
6 ответов
- Назначение их первичным ключом приведет к уникальности (а не подразумевает ее).
- Предположительно, первичный ключ будет кластеризован (в зависимости от dbms), что улучшит производительность для некоторых запросов.
- Это экономит место на добавление уникального ограничения, которое в некоторых СУБД также создает уникальный индекс.
Независимо от того, сделаете ли вы эти три ключа первичными или нет, вам все равно потребуется какое-то ограничение уникальности, чтобы гарантировать, что ученик не может быть дважды связан с одним и тем же сеансом и session_subject_id. Если этот сценарий разрешен, вам нужно будет расширить ограничение уникальности, включив в него еще один столбец.
Независимо от того, какой выбор вы сделаете, у вас обязательно должно быть какое-то ограничение уникальности для таблицы.
Если вы обсуждаете, создавать ли суррогатный первичный ключ + уникальное ограничение для трех столбцов, я бы сказал, что это зависит от того, будут ли в этой таблице дочерние таблицы. Если да, то ссылаться на суррогатный ключ будет проще и проще. Если этого не произойдет, то ИМО, суррогатный ключ на самом деле не дает вам многого, и вы также можете использовать три столбца в качестве PK.
Споры о естественных и искусственных ключах так же стара, как и любая реализация базы данных. Читать о "за" и "против" в википедии .
Аргументы в пользу суррогатных ключей легко оспариваются на теоретическом уровне (например, аргумент о том, что с естественными ключами вы рискуете, что ваш PK станет неуникальным, может быть опровергнут ответом - хорошо! Если я столкнусь с такой ситуацией, он хорошо, что вместо того, чтобы иметь искусственно уникальные первичные ключи с повторяющимися записями для фактических данных, что-то сломалось).
Еще один хороший аргумент - то, что искусственные ключи либо избыточны (в таблице есть еще один уникальный ключ), либо они позволяют хранить существенно неуникальные записи.
Тем не менее, найти хорошие естественные ключи иногда настолько сложно, что вы должны выбрать что-то искусственное и допустить ситуацию, когда у вас будет человек с тем же именем, рожденный в тот же день (или с неизвестной датой), с другими свойствами xy, которые одинаковы по стоимости.
Также не так ясно, что искусственно, а что естественно. Вы можете сказать, например, что SSN естественен для ваших данных. Хотя это действительно составленное число.
Что касается производительности многоклавишных отношений - это не так плохо, как вы думаете, более того - индексы сегментируются естественным образом, и с такими ключами вы обычно получаете базу данных, которая действительно хорошо работает с общими запросы без дополнительных индексов.
Если вы серьезно относитесь к этим проблемам и пытаетесь построить сложную систему, прочтите хорошую литературу ( CJDate На ум приходит Введение в системы баз данных, в настоящее время в 8-м издании)
{ {1}}Я бы действительно рекомендовал вам использовать первичный ключ, который сгенерирован для вас выбранной вами базой данных. В основном потому, что если вы измените структуру этой таблицы во время любого будущего обслуживания, вы рискуете, что ваш уникальный ключ станет неуникальным. Это может быть действительно сложной проблемой. Кроме того, наличие уникального первичного ключа значительно упрощает запросы к таблице.
Уникальные идентификаторы для 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
Единственная причина сделать их составным первичным ключом - это обеспечить один комментарий на студента/сеанс/предмет. Если вы не хотите этого делать, я бы не стал создавать еще один ключ.
Это зависит от остальной части приложения.
Если у вас не будет внешних ключей для таблицы комментариев (что кажется вероятным), это нормально.
Если вам нужно сослаться на комментарии из другой таблицы, лучше создать уникальный индекс с тремя полями и первичным ключом AutoNumber , который будет использоваться в другие таблицы в качестве внешнего ключа (намного проще и дешевле, чем 3 поля).
FOREIGN ключи могут содержать NULL, что недопустимо в PRIMARY ключах. Лучшее, что вы можете сделать, - это создать УНИКАЛЬНЫЙ индекс из столбцов.
Создайте ПЕРВИЧНЫЙ ключ на таблице.
Ответ: Мой следующий вопрос: Есть ли возможность перекрытия между ключами из 4 таблиц?
Эти две могут создать один и тот же составной ключ 101010101: ученик: 1010, сеанс: 10, тема: 10, пользователь: 1 студент: 10, сеанс: 1010, тема: 10, пользователь: 1
Я просто указываю, что в четырех столбцах должны быть явно разные домены для уменьшения возможности перекрытия.
Вероятно, лучше всего использовать настоящий первичный ключ.