Question

Our Company is developing a CRM and we came now to the point where we have to decide how we want to handle the releationships. This is an important point because there are going to be tons of them. And changing the structure later would be simply not cool..

I know 3 ways how we could do it:

One releationship table:

The way i would do this is creating one table holding all the releationships.

Table: releationships

+----+-------------+-----------+--------------+------------+
| id | record_type | record_id | belongs_type | belongs_id |
+----+-------------+-----------+--------------+------------+
| 1  | person      | 42        | company      | 12         |
+----+-------------+-----------+--------------+------------+
| 2  | person      | 43        | company      | 12         |
+----+-------------+-----------+--------------+------------+
| 3  | note        | 23        | company      | 12         |
+----+-------------+-----------+--------------+------------+ 
| 4  | attachment  | 13        | company      | 12         |
+----+-------------+-----------+--------------+------------+

Multiple releationship tables:

I think this is the way how it for example the SugarCRM does.

Table: company_realationships

+----+-----------+------------+--------+
| id | record_id | has_type   | has_id |
+----+-----------+------------+--------+
| 1  | 12        | person     | 42     |
+----+-----------+------------+--------+
| 2  | 12        | person     | 43     |
+----+-----------+------------+--------+
| 3  | 12        | note       | 23     |
+----+-----------+------------+--------+
| 2  | 12        | attachment | 13     |
+----+-----------+------------+--------+

All in the record table:

Table: person

+----+-----------+------------+
| id | name      | company_id |
+----+-----------+------------+
| 42 | luke      | 12         |
+----+-----------+------------+
| 43 | other guy | 12         |
+----+-----------+------------+

ect.

• So my Question is wich is the Best way of handling lots of releationships?
• Are there other ways to do it?
• What are disadvantages / advantages?
• Is there a special way how hightraffic sides handle their releationships?

Thanks for your help guys 🙂

Answer 1

So my Question is wich is the Best way of handling lots of releationships?

The third one or the variation of it (see below).

Every “M:N” relationship should be represented by its own junction table. OTOH, a “1:N” relationship doesn’t need additional table – just a proper foreign key in the table on the side of the “N”.

If I understand your description correctly, the third option models a 1:N relationship between company and person. If by any chance you wanted to model a M:N relationship between them, you’d have a junction table: company_person ( company_id, person_id, PK (company_id, person_id) ).

Are there other ways to do it?

Sometimes, inheritance (aka. category, subtype, generalization hierarchy etc.) can be used to lower the number of possible “relatable” combinations. In a nutshell, make a relationship to a parent, then every child inherited from that parent is automatically involved in that relationship.

For an example, take a look at this post.

What are disadvantages / advantages?

Enforcing constraints (including FKs) declaratively is better (less prone to errors and probably more performant) than enforcing them through triggers, which is again better than enforcing them in the client code.

Choose a design that better adheres to that principle. For example, your options 1 and 2 don’t allow the DBMS to enforce FKs declaratively.

Is there a special way how hightraffic sides handle their releationships?

Good logical design followed by good physical implementation is the only solid basis for good performance. It’s hard to “bolt-on” the performance on top of a bad design.

Perhaps, you’d like to take a look at:

• ERwin Methods Guide
• Use The Index, Luke!

And when it comes to performance, don’t guess! Measure on realistic amounts of data.