Best Practice: Primary key in joing table

hi there,

i have the following joining table (many-to-many relationship)...

CREATE TABLE [dbo].[products_to_products_swatch] (
[products_to_products_swatch_id] [int] IDENTITY (1, 1) NOT FOR REPLICATION NOT NULL ,
[product_id] [int] NOT NULL ,
[products_swatch_id] [int] NOT NULL
) ON [PRIMARY]
GO

question: do i need to include a primary key in this table - being that it is a joing table?

thanks
mikejoing table ? i mean joining table :o)|||If this is simply implementing a many-to-many join, then there is no need for a surrogate key. Just declare a composite primary key consisting of the foreign keys to both tables.
If you are storing additional information regarding the relationship (timestamp, notes, modifier, whatever) you may want to include a surrogate key for developmental consistency with your other tables, but it is not required.

Best practice for relationship

Hi,

There is an idea that using relationship is not suitable in big Database (or Application).

I had checked some big Application : SharePoint Portal(2003 & 2007),

Biztalk Server and see that Microsoft dont use (even one) relatopnships in database.

Everybody, comments plz!

MA.

yes that's a behaviour that MS system tables have...i can comment on sql server system DB , rest of its product i guess must follow the same pattern....see relations (-explicit implementation) are basically constraints (or shud i say we put say a foreign key to enforce a relationship..and ask DB engine to check it (relationship) for us while we do insert/update)..so if ur sure that u wont enter wrong values in the related tables, u can save the effort of db engine testing it for u....the system SP and dll which update system views/tables(in 2000 sql server) take care that all tables data is kept in sync C of ACID properties .....