Reading this article makes me very nervous. I've seen so many performance issues arise from approaches similar to this. While you didn't make a statement on it, most readers might think it is implied that the Primary Key is clustered & that no other constraints exist on the table.

So whether you can them Join Tables, Bridge Tables or something else. A couple of key things to consider.

1. Most likely this is a Many:Many Join. But each specific M:M join can only happen once. So you need to enforce uniqueness by either a) Making the Primary Key a Composite of the Foreign Keys. (improves joins from one side of the Many to the other) OR b) Have a Unique Constraint on the Foriegn Keys (this prevents the Join Table, exploding with Duplicate entries, who's INSERTS should've failed & been forced to be an UPDATE instead.

2. If your data is not permitted to be deleted. (unless archived), and you often do lots of reporting on it. You are likely to get better perf by carrying the "composite key (multiple FK's)" into the 3rd or 4th table as part of their key. This will let you create much more efficient joins & not require lots of tables to be joined into the query.

In short having an ID for each table, might not be the best plan. Especially if your schema lends itself into logical groupings. eg: 5 tables describe the Employee Training tables, another 6 describe Employee Performance etc. So you carry the FK's till you get 3 to 5 FK's making 1 Primary key before you generate a unique ID column which the other functional area joins with.

Hope this is useful

Dave