Ai-je besoin d'une colonne d'ID distincte pour cette table de «mappage»?

J'ai un tableau de Producerset un tableau de Products, qui sont tous les deux de la forme:

• Id - int, clé primaire
• Name - nvarchar

Un producteur peut transporter plusieurs produits, donc j'allais créer une table appelée ProducerDetailsqui aurait:

• ProducerId - int, clé étrangère vers Producers.Id
• ProductId - int, clé étrangère vers Products.Id

Puis j'ai commencé à me poser des questions, alors j'ai pensé demander aux experts. Serait-il préférable de concevoir une base de données pour avoir une Idcolonne supplémentaire (int, clé primaire) dans ma ProducerDetailstable? Ou est-ce inutile?

J'utilise SQL-Server 2008 R2 si cela fait une différence.

EDIT - La relation entre ces tables serait plusieurs à plusieurs je crois, désolé de ne pas l'avoir précisé. Un producteur peut transporter plusieurs types de produits et le même produit peut être fabriqué par plusieurs producteurs différents.

_{Je m'excuse si cette question est trop simple, l'intégrité référentielle / la conception de base de données n'est pas mon point fort (bien que j'essaie d'améliorer cela).}

Si vous avez une relation un-à-plusieurs entre les producteurs et les produits (en d'autres termes, un produit ne peut appartenir qu'à un seul producteur), il serait logique de simplement mettre une référence de clé étrangère directement dans votre Productstableau:

Un à plusieurs

create table Producer
(
    id int identity(1, 1) not null primary key clustered,
    Name varchar(100) not null
)
go

create table Product
(
    id int identity(1, 1) not null,
    Name varchar(100) not null,
    ProducerId int not null foreign key references Producer(id)
)
go

Mais s'il y a une chance que ce soit une relation plusieurs-à-plusieurs, alors votre meilleur pari serait d'utiliser une table Join.

Plusieurs à plusieurs

create table Producer
(
    id int identity(1, 1) not null primary key clustered,
    Name varchar(100) not null
)
go

create table Product
(
    id int identity(1, 1) not null primary key clustered,
    Name varchar(100) not null
)
go

create table ProductProducer
(
    ProductId int not null foreign key references Product(id),
    ProducerId int not null foreign key references Producer(id)
)
go

-- adding the primary key also ensures uniqueness
alter table ProductProducer
add constraint PK_ProductProducer 
primary key (ProductId, ProducerId)
go

Si vous décidez d'utiliser la table Join, vous n'auriez pas besoin d'avoir une clé supplémentaire, car la combinaison de ProductId/ProducerIdserait finalement unique. Vous pouvez les utiliser comme clé composite, vous n'avez donc pas besoin de ce Idchamp supplémentaire ProductProducer.

Non, il n'y a aucune valeur à ajouter une "clé primaire" supplémentaire à ce tableau. Votre jointures ne sont jamais à se référer à ProducerIDet ProductID, donc il est juste poids mort. A MON HUMBLE AVIS.

Bien que je convienne avec @Shark que la table de jointure ne semble même pas nécessaire ici, à moins que vous ne fassiez tout votre possible pour ne pas modifier le schéma des tables existantes de quelque manière que ce soit.

En passant, je pense également qu'il vaut la peine de nommer votre identifiant principal en entier (par exemple Products.ProductIDau lieu de Products.ID) afin que l'identifiant soit nommé de manière cohérente dans tout le schéma.