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

Question

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

Например, у меня могут быть таблицы A и B, каждая из которых имеетID и таблицу с именем A_B, которая имеет кортеж внешнего ключа (A_ID, B_ID).Но должен ли A_B иметь свой собственный столбец идентификатора с автоинкрементным первичным ключом или нет?

Каковы преимущества и недостатки его добавления?Лично мне нравятся естественные ключи для многих ко многим соединениям.Но какое дополнительное преимущество добавит первичный ключ?

Answer 1

Я согласен со всем, что сказал Одед, за исключением

«Он также не может быть разумно использован в качестве внешнего ключа».

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

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

Итак, разработайте таблицу заказов, в которой хранятся новые заказы автомобилей.Очевидно, цвет и модель будут на столе заказа.Если вы сделаете FK для каждой из этих таблиц, база данных позволит выбрать неправильную комбинацию модель / цвет.(Конечно, вы можете применить это с помощью кода, вы не можете сделать это декларативно.) Если вы сделаете родителя таблицей many: many, вы получите только те комбинации, которые были указаны.

Итак, вы бы предпочли иметь многоколоночный FK и указать на PK, построенный на ModelID и ColorID, или вам нужен один столбец FK?

Выберите яд.

РЕДАКТИРОВАТЬ

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

Answer 2

Такой суррогатный ключ не добавляет ничего, кроме накладных расходов.

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

Расширить:

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

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

Он также не может быть разумно использован в качестве внешнего ключа.

Answer 3

Часто используется термин «таблица соединений», но я не думаю, что когда-либо видел его правильно определенным или объясненным. Лично я избегаю использовать этот термин. Насколько я понимаю, «таблица соединений» означает любую таблицу с двумя внешними ключами (или, возможно, более чем двумя?).

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

Answer 4

Я сделал это в обе стороны. Иногда это полезно для добавления функции в будущем. Например, если когда-нибудь в строке таблицы будет содержаться что-то большее, чем просто 2 идентификатора. Если вам не хватает места, я бы положил туда только потому, что это не повредит. Иногда это может мешать работе инструментов ORM, таких как hibernate или ADO.NET, но это не так.

Итак, чтобы подвести итог ... ПРОФИ 1. Позволяет потенциальному будущему росту.

СВОД 1. Космос 2. Смущает некоторые инструменты ORM.

Answer 5

Это действительно не дает ничего полезного. Имейте в виду назначение ключа, который заключается в уникальной ссылке на «что-то». Такая ассоциативная таблица сама по себе не является «чем-то», а скорее является структурой персистентности для двух других «чего-то», у которых уже есть ключи. Вне среды персистентности (базы данных) она не имеет смысла и даже не должна существовать или быть известной (например, в бизнес-сфере), поэтому никогда не будет (и не будет) причины ссылаться на нее свой собственный идентификатор.