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

У меня есть таблица (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 будет однозначно идентифицировать комментарий об этом студента на этой сессии тему.

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

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

источник

2010-03-30 Carvell Fenton

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

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

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

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

источник

2010-03-30 14:34:35 Thomas

. Вы имели в виду: «Если это невозможно, то вам нужно будет расширить ограничение уникальности, чтобы включить другой столбец ».? –

На самом деле, я был изначально правильно, просто сформулировал плохо. Я исправил. Если, по сути, три столбца не уникальны, тогда вам нужно будет явно расширить ограничение уникальности. – Thomas

Ах! Получил это сейчас. Благодаря! –

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

Уникальные идентификаторы для 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

источник

2010-03-30 14:26:09 Ceilingfish

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

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

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

источник

2010-03-30 14:27:17

Итак, просто для того, чтобы уточнить, так как я хочу только, чтобы на одном студенте/сессии/теме был один комментарий, вы говорите, что идете с композитным, а не с автоинкрементным ключом? Я только что смутился вашим последним предложением. –

Если вам действительно нужен только один комментарий для ученика/сессии/темы, вы можете создать составной уникальный ключ для этих трех полей. Нет необходимости вносить их в составной первичный ключ, хотя это будет иметь тот же эффект.Вы все равно хотите проверить на уровне приложения, но единственное ограничение обеспечит соблюдение одного правила комментариев. –

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

Создайте PRIMARY ключ на столе.

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

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

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

Наверное, лучше всего использовать истинный первичный ключ.

источник

2010-03-30 14:27:33 wbogacz

Я предотвращаю NULL, поэтому, если это так, вы бы отстаивали составной ключ? –

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

Возможно, это ТОЛЬКО мера безопасности, но это безопасность, которую я бы хотел. Если внешние ключи не так упрощены, как мой пример выше, вы уменьшаете, но не исключаете возможность ошибочных объединений. – wbogacz

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

источник

2010-03-30 14:37:01

+1 Этот ответ тоже помог, я принял Томаса, потому что я подумал, что это немного более полно. Иногда мне нужно много информации для меня, чтобы понять суть дела! :) –

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

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

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

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

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

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

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

источник

2010-03-30 15:04:37 Unreason

+1 для справки и дополнительного обсуждения. Благодарю. –

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

ответ

Смежные вопросы