MS SQL создает отношение "многие ко многим" к таблице соединений

Я использую Microsoft SQL Server Management Studio и, создавая таблицу соединений, должен ли я создать столбец идентификатора для таблицы соединений, если это так, я также должен сделать его первичным ключом и столбцом идентификации? Или просто сохранить 2 столбца для таблиц, к которым я присоединяюсь в отношении "многие ко многим"?

Например, если это будет много-много таблиц:

[и сделайте Movie_Category_Junction_ID мой основной ключ и используйте его как колонку Identity)?

[и просто оставьте это при отсутствии первичного ключа или таблицы идентификации]?

Ответы

Ответ 1

Я бы использовал вторую таблицу соединений:

MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID

Первичным ключом будет комбинация обоих столбцов. У вас также будет внешний ключ из каждого столбца в таблицу Movie и Category.

Таблица соединений будет выглядеть примерно так:

create table movie_category_junction
(
  movie_id int,
  category_id int,
  CONSTRAINT movie_cat_pk PRIMARY KEY (movie_id, category_id),
  CONSTRAINT FK_movie 
      FOREIGN KEY (movie_id) REFERENCES movie (movie_id),
  CONSTRAINT FK_category 
      FOREIGN KEY (category_id) REFERENCES category (category_id)
);

См. SQL Fiddle with Demo.

Использование этих двух полей в качестве PRIMARY KEY предотвратит добавление дубликатов комбинаций фильмов и категорий в таблицу.

Ответ 2

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

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

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

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

Вы можете поместить уникальный индекс в два поля, чтобы избежать дублирования. Это даже предотвратит дублирование, если у вас есть отдельный ключ автоматического назначения. Вы можете использовать оба поля в качестве основного ключа (который также является уникальным индексом).

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

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

Ответ 3

Я бы пошел со второй таблицей. Но сделайте эти два поля первичными. Это ограничит повторяющиеся записи.