web-dev-qa-db-fra.com

MS SQL créant une relation plusieurs-à-plusieurs avec une table de jonction

J'utilise Microsoft SQL Server Management Studio et lors de la création d'une table de jonction, dois-je créer une colonne ID pour la table de jonction, si oui, devrais-je également en faire la clé primaire et la colonne d'identité? Ou simplement conserver 2 colonnes pour les tables que je joins dans la relation plusieurs-à-plusieurs?

Par exemple, si ce sont les tables plusieurs à plusieurs:

MOVIE
Movie_ID
Name
etc...

CATEGORY
Category_ID
Name
etc...

Dois-je faire la table de jonction:

MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID
Movie_Category_Junction_ID

[et faites le Movie_Category_Junction_ID ma clé primaire et l'utiliser comme colonne d'identité]?

Ou:

MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID

[et en rester là sans clé primaire ni table d'identité]?

sqlsql-servermany-to-manyjunction-table
29
sc00ctbr

J'utiliserais la deuxième table de jonction:

MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID

La clé primaire serait la combinaison des deux colonnes. Vous auriez également une clé étrangère de chaque colonne vers la table Movie et Category.

La table de jonction ressemblerait à ceci:

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)
);

Voir SQL Fiddle with Demo .

En utilisant ces deux champs comme PRIMARY KEY empêchera les combinaisons de films/catégories en double d'être ajoutées au tableau.

49
Taryn

Il existe différentes écoles de pensée à ce sujet. Une école préfère inclure une clé primaire et nommer la table de liaison quelque chose de plus significatif que les deux tables qu'elle relie. Le raisonnement est que, bien que le tableau puisse commencer comme une simple table de liaison, il peut devenir son propre tableau avec des données importantes.

Un exemple est un plusieurs-à-plusieurs entre les magazines et les abonnés. Vraiment, ce lien est un abonnement avec ses propres attributs, comme la date d'expiration, l'état du paiement, etc.

Cependant, je pense que parfois une table de liaison est juste une table de liaison. La relation plusieurs à plusieurs avec les catégories en est un bon exemple.

Ainsi, dans ce cas, une clé primaire distincte d'un champ n'est pas nécessaire. Vous pourriez avoir une clé d'affectation automatique, qui ne nuirait à rien et faciliterait la suppression d'enregistrements spécifiques. Cela peut être une bonne pratique générale, donc si la table se développe plus tard en une table significative avec ses propres données significatives (en tant qu'abonnements), elle aura déjà une clé primaire à attribution automatique.

Vous pouvez mettre un index unique sur les deux champs pour éviter les doublons. Cela empêchera même les doublons si vous disposez d'une clé d'attribution automatique distincte. Vous pouvez utiliser les deux champs comme clé primaire (qui est également un index unique).

Ainsi, la seule école de pensée peut s'en tenir à des clés primaires à attribution automatique entière, et évite les clés primaires composées. Ce n'est pas la seule façon de le faire, et peut-être pas la meilleure, mais cela ne vous mènera pas à un problème où vous le regretterez vraiment.

Mais, pour quelque chose comme ce que vous faites, vous serez probablement d'accord avec seulement les deux champs. Je recommanderais toujours de faire des deux champs une clé primaire composée, ou au moins de mettre un index unique sur les deux champs.

17
Marlin Pierce

J'irais avec la 2ème table de jonction. Mais définissez ces deux champs comme clé primaire. Cela limitera les entrées en double.

2
higgs_boson