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 TA         


        

Answer 1

Given that the TableAId-TableBId combination is unique and that the table is used solely to implemet a many-to-many relationship I would go with the second option. From a purely logical standpoint the fist implemtnation reduces to the second. From a structural perspective your databases needs to maintain both a primary key/index as well as a constraint on the first implementation wereas on the second it only needs to maitain the primary key/index.

Answer 2

The second is better. It constrains the junction box (intersection box) to not having more than one appearance of the same pair. If there are no other columns in the junction box, you won't be doing lookups of this table anyway, except by way of the two foreign keys.

Answer 3

Use version-1 if your "intersection" actually IS an entity on its own, meaning:

• it has additional properties
• you may search for those objects (and not navigating a relation)

User version-2 if it is purely N-M relation table. In which case also make sure that:

• you have your PK (CLUSTERED) with the first column relating to the table your search more often: for example if your tables are Person-Address, then I would assume that you would search for all-addresses-of-a-person more often then for all-people-at-this-address. So you should put your PK to include PersonID first

• you can still have another one-column UNIQUE identifier, but just:

  1. either do not make it a PK
  2. or make it a PK, but specify NON CLUSTERED, so that you can use CLUSTERED for the UNIQUE index covering two referencing columns
  3. unless you use GUIDs by your design, you could then stick to INT IDENTITY column type

In both cases you may want to create another INDEX covering the 2 columns, but in another order, if you search from the other side of the relation often.

Answer 4

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.

Answer 5

Benefits of the first one:

The ability to look up the join table by a single value. This makes some look up operations simpler on the client side.

Some ORMs (NHibernate) also require ids in each entity for persistence to work properly.

Benefits of the second one:

Simpler data model, with no need to create the additional index.

Less memory required.