Должен таблица базы данных, которая содержит два столбца, которые являются внешними ключами, имеют третий столбец, который является первичным ключом?
Я предполагаю не, так как внешние ключи являются первичными ключами в своих собственных таблицах, таким образом, они будут уникальны.
Подробнее
Я использую MySQL, и следующие три таблицы используют InnoDB механизм.
======================= =======================
| galleries | | images |
|---------------------| |---------------------|
| PK | gallery_id | | PK | image_id |
| | name | | | title |
| | description | | | description |
| | max_images | | | filename |
| | enabled | | | enabled |
======================= =======================
========================
| galleries_images |
|----------------------|
| FK | gallery_id |
| FK | image_id | <----- Should I add a PK to this table?
========================
Эпилог
Спасибо за превосходные ответы. Я узнал о составных ключах и после рассмотрения моего конкретного случая, я решил сделать image_id столбец в galleries_images представьте первичный ключ в виде таблицы. Таким образом, изображения могут только быть связаны с одной галереей, которая является тем, что я хочу.
Я также собираюсь реализовать a order_num столбец в galleries_images который я буду использовать логику PHP для поддержания. Таким образом, пользователь может поместить изображения в определенный порядок в каждой галерее. Я закончил с этим:
============================
| galleries_images |
|--------------------------|
| PK, FK | image_id |
| FK | gallery_id |
| | order_num |
============================
Еще раз спасибо!
Эпилог II
Благодаря тем из Вас, кто указал, что мне даже не была нужна эта таблица. Я не предоставил большую часть полной информации для начала. Я закончил тем, что отбросил galleries_images таблица в целом и просто добавила gallery_id как внешний ключ к images таблица. Так или иначе я все еще узнал больше, чем я думал, что буду и быть благодарным за справку.
6 ответов
Все таблицы должны иметь первичный ключ.
Однако нет необходимости создавать новый суррогатный столбец, который будет выступать в качестве первичного ключа. Взяв пример Джона, было бы вполне приемлемо иметь составной первичный ключ с двумя полями первичного ключа из других таблиц и полем даты.
С прагматической точки зрения, хотя иногда создание нового суррогатного столбца может быть проще для работы, чем составной, хотя, если PK сам ссылается в еще одной таблице или для привязки к различным элементам управления, которые не обрабатывают составной первичный столбец Ключ в порядке.
Редактировать
После обновления вашего вопроса я бы просто сделал составной первичный ключ для gallery_id, image_id. Я не вижу пользы от добавления нового столбца.
Если одно конкретное изображение может быть связано только с одной галереей, то комбинации в вашей таблице галереи-изображения уникальны, и вы можете использовать эту пару полей в качестве PK.
Если комбинации галереи-изображения могут быть продублированы ИЛИ
если ваша схема включает больше таблиц, которые могут быть дочерними по отношению к этим изображениям-галереям,
ТОГДА я бы посоветовал вам включить дополнительное поле, которое будет PK.
Этот ответ связан с его блокирующим вопросом: я знаю, это должна быть новая тема, но неважно. Пожалуйста, не голосуйте против просто за это.
Например, вы можете создать таблицу Order_image_lock (ID галереи (первичный ключ), start_time).
Создайте 3 метода / спрока: GetLock, CheckLock, DropLock.
Когда вы хотите изменить порядок портфолио, вы вызываете GetLock, который вставляет (gallary_id, sysdate).
Если это сработает, можно продолжить. Если это не удается на ПК, кто-то другой переупорядочивает, вызывает исключение.
Когда вы будете готовы к изменению порядка, вызовите CheckLock, чтобы проверить, все ли у вас блокировка (вы увидите, почему), если она у вас есть, обновите переупорядоченные значения, если не перейдите в GetLock.
Когда вы закончите, DropLock Удаляет запись.
Серверный процесс может очистить таблицу от блокировок старше x минут. Для тех, кто отключился, или для людей, которые оставляют экран поднятым и отправляются на обед.
Добавьте в эту таблицу столбец user_id, чтобы вы могли сообщить, у кого есть блокировки, которые могут понадобиться другому пользователю.
Это будет масштабироваться намного лучше, чем фактическая блокировка строк. некоторые БДМ имеют ограниченное количество блокировок, что вынуждает их выполнять `` эскалацию блокировки '', когда несколько блокировок строк преобразуются в блокировку страницы, пока не будет слишком много блокировок страниц, и преобразуются в блокировку таблицы ... вам нужно проверить, как ваши RDBM работают с большими объемами блокировок ... если вы планируете масштабирование.
Теоретически, если комбинация двух внешних ключей (FK) уникальна в таблице или если комбинация двух FK плюс некоторый другой столбец уникальна, то таблица имеет составной первичный ключ и нет Строгая необходимость ввести другой ключ в качестве суррогатного первичного ключа. Однако нередко обнаруживается, что люди добавляют дополнительный ключ. Частично это зависит от того, для чего еще будут использоваться данные в таблице с составным первичным ключом. Если он описывает что-то, что само по себе будет иметь связанные с ним строки из других таблиц, тогда может иметь смысл ввести простой PK.
Некоторое программное обеспечение, похоже, требует простых PK, хотя реляционная модель данных не требует.
Ответ обычно "да". Тип таблицы, который вы описываете, - это ассоциативная таблица, которая хранит ассоциации. Поскольку эти записи интересны сами по себе, и поскольку вы, вероятно, захотите найти их позже, они должны иметь значимую идентификацию.
Например, возможно, у вас есть таблица players и таблица matchups для вашей теннисной лиги. matchups может содержать не более чем внешние ключи двух игроков, которые играли друг против друга; это ассоциация между двумя игроками.
Но позже вы можете захотеть записать другую информацию, специфичную для этой ассоциации: время проведения матча, счет игры и так далее. И, конечно, как только вы захотите провести более одного матча между одними и теми же двумя игроками, вам нужно будет различать каждый матч. Таким образом, вы захотите дать каждому matchup свой собственный идентификатор в виде первичного ключа.
Обновление:
========================
| galleries_images |
|----------------------|
| FK | gallery_id |
| FK | image_id | <----- Should I add a PK to this table?
========================
В вашем конкретном примере, вероятно, полезно иметь первичный ключ. Как только вам понадобится записать какие-либо метаданные об ассоциации, вы захотите иметь этот первичный ключ. Кроме того, если одно и то же изображение может быть добавлено в одну и ту же галерею несколько раз, первичный ключ будет необходим для различения двух записей.
Вы говорите, что внешние ключи являются первичными ключами в их собственных таблицах. Это означает, что они уникальны в этих таблицах. Однако это не означает, что они уникальны в этой таблице.
Обычно я обнаружил, что лучше всего создавать первичный ключ в таблице базы данных. Рано или поздно вы обнаружите, что он вам нужен, так почему бы не включить новый первичный ключ с самого начала?