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


Then I started to question myself, so I thought I'd ask the experts.  Would it be better database design to have an additional Id (int, Primary key) column in my ProducerDetails table?  Or is that unnecessary?

I'm using SQL-Server 2008 R2 if that make any difference at all.

EDIT - The relationship between these tables would be many-to-many I believe, sorry I didn't make that clear.  A producer can carry multiple types of products, and the same product could be produced by multiple different producers.

I apologize if this question is overly simple, referential integrity / database design is not my strongsuit (although I'm trying to improve that).
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.