Question

I wasnt sure how best to word this title, or even explain the problem but here goes…

I am designing an SQL database with several tables that can be linked together.
i.e.

TABLE a ID1 CAN BE JOINED TO TABLE b ID1
TABLE b ID2 CAN BE JOINED TO TABLE c ID1
TABLE d ID1 CAN BE JOINED TO TABLE a ID5

etc.

Basically any row in any table can be linked to any other row in any table (including itself)

i was going to create a single “Connections” table with the following columns…

Table 1 Name VARCHAR()
Table 1 ID   INT()
Table 2 Name VARCHAR()
Table 2 ID   INT()

Acting as a many to many joining table but with columns for the table as well as ID of each side of the connection. I get the feeling this isn’t best practise though. Any thoughts?
I cant believe i need to create an individual table for each permutation of connection!

Answer 1

This problem is common, opposing the normalized model to the denormalized model.

To implement a meta-model (one table to store all relations) most commonly has the following issues:

• Slower requests in case of 0..n relations (at least)
• No native management of relational constraints (on cascade…)
• Needs an additional applicative layer to parse the relations

Then if you don’t mind it, your solution is fine.

Cheers,
S.