Do I need a separate Id column for this "mapping" table?

I have a table of Producers and a table of Products, both of which are of the form:

• Id - int, Primary key

• Name - nvarchar

A Producer can carry multiple Products, so I was going to create a table called ProducerDetails that would have:

• ProducerId - int, Foreign key to Producers.Id

• ProductId - int, Foreign key to Products.Id

Would it be better database design to have an additional Id (int, Primary key) column in my ProducerDetails table?

I'm using SQL Server 2008 R2.

The relationship between these tables is many-to-many. A producer can carry multiple types of products, and the same product could be produced by multiple different producers.

No, there is no value in adding an additional "primary key" to this table. Your joins are only ever going to refer to ProducerID and ProductID, so it is just dead weight. IMHO.

Though I agree with @Shark that the join table doesn't even seem to be needed here, unless you are going out of your way to not change the schema of the existing tables in any way.

As an aside, I also think it is worthwhile to name your primary identifier in full (e.g. Products.ProductID instead of Products.ID) so that the identifier is consistently named throughout the schema.

StackExchange Database Administrators Q#15878, answer score: 8