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

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

Некоторые программы, по-видимому, требуют простых PKs, хотя реляционная модель данных этого не делает.

Ответ обычно "да". Тип таблицы, которую вы описываете, - это таблица ассоциаций , в которой хранятся ассоциации. Поскольку эти записи интересны сами по себе, и поскольку вы, вероятно, захотите посмотреть их позже, они должны иметь значимую идентичность.

Например, возможно, у вас есть таблица players и таблица matchups для вашей теннисной Лиги. matchups может содержать не более чем внешние ключи двух игроков, которые играли друг против друга; это ассоциация между двумя игроками. Но позже вы можете записать другую информацию, специфичную для этой ассоциации: время, когда произошел матч,счет игры и т. д. И, конечно, как только вы хотите иметь более одного матча между теми же двумя игроками, вам нужно будет различать каждый матч. Таким образом, вы захотите дать каждому matchup свою собственную идентичность в виде первичного ключа.

---

Обновление:

========================
| galleries_images     |
|----------------------|
| FK | gallery_id      |
| FK | image_id        |  <----- Should I add a PK to this table?
========================

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

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

Этот ответ имеет отношение к его блокирующему вопросу: я знаю, должна быть новая тема, но все равно. Пожалуйста, не понижайте голос просто за это.

Например, можно создать таблицу Order_image_lock (идентификатор галереи (первичный ключ), start_time).

Создать 3 метода / sprocs: GetLock, CheckLock, DropLock.

Когда вы хотите изменить порядок портфолио, Вы вызываете GetLock, который вставляет (gallary_id, sysdate).

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

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

Когда вы закончите, DropLock удалит запись.

Серверный процесс может проверять таблицу на наличие блокировок, возраст которых превышает x минут. Для разъединителей или людей, которые оставляют экран и идут на обед.

Добавьте столбец user_id в эту таблицу, чтобы вы могли сообщить о том, кто имеет то, что блокирует другой пользователь может хотеть.

Это будет масштабироваться намного лучше, чем фактическая блокировка строк. некоторые СУБД имеют конечное количество блокировок, что вынуждает их выполнять "эскалацию блокировок", когда несколько блокировок строк преобразуются в блокировку страницы, пока не останется слишком много блокировок страниц, и преобразуются в блокировку таблицы... вам нужно проверить, как Ваша СУБД работает с большими томами блокировки... если вы планируете масштабировать.

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

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