Many to Many Relation Design - Intersection Table Design

Question

I'm wondering what a better design is for the intersection table for a many-to-many relationship.

The two approaches I am considering are:

CREATE TABLE SomeIntersection  (      IntersectionId UNIQUEIDENTIFIER PRIMARY KEY,      TableAId UNIQUEIDENTIFIER REFERENCES TableA NOT NULL,      TableBId UNIQUEIDENTIFIER REFERENCES TableB NOT NULL,      CONSTRAINT IX_Intersection UNIQUE(TableAId, TableBId ) )  

or

CREATE TABLE SomeIntersection  (      TableAId UNIQUEIDENTIFIER REFERENCES TableA NOT NULL,      TableBId UNIQUEIDENTIFIER REFERENCES TableB NOT NULL,      PRIMARY KEY(TableAId, TableBId ) )  

Are there benefits to one over the other?
EDIT 2:****Please Note: I plan to use Entity Framework to provide an API for the database. With that in mind, does one solution work better with EF than the other?

EDIT: On a related note, for a intersection table that the two columns reference the same table (example below), is there a way to make the two fields differ on a record?

CREATE TABLE SomeIntersection  (      ParentRecord INT REFERENCES TableA NOT NULL,      ChildRecord INT REFERENCES TableA NOT NULL,      PRIMARY KEY(TableAId, TableBId ) ) 

I want to prevent the following

ParentRecord          ChildRecord =================================       1                    1         --Cyclical reference!  

Answer 1

It's a topic of some debate. I prefer the first form because I consider it better to be able to look up the mapping row by a single value, and like to enforce a perhaps-foolish consistency of having a single-column primary key available in every table without fail. Others think that having that column is a silly waste of space.

We meet for a few rounds of bare-knuckle boxing at a bar in New Jersey every couple of months.