我们公司正在开发 CRM，现在我们到了必须决定如何处理关系的地步。这一点很重要，因为将会有很多。以后再改变结构就不太酷了..
我知道 3 种方法:
一张关系表:
我这样做的方法是创建一个包含所有关系的表。
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 |
+----+-------------+-----------+--------------+------------+
多个关系表:
我认为这就是 SugarCRM 的工作方式。
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 |
+----+-----------+------------+--------+
全部在记录表中:
Table: person
+----+-----------+------------+
| id | name | company_id |
+----+-----------+------------+
| 42 | luke | 12 |
+----+-----------+------------+
| 43 | other guy | 12 |
+----+-----------+------------+
等等。
- 所以我的问题是处理大量关系的最佳方法是什么？
- 还有其他方法吗？
- 有什么缺点/优点？
- 高流量双方是否有一种特殊的方式来处理他们的关系？
谢谢你们的帮助:)
最佳答案
So my Question is wich is the Best way of handling lots of releationships?
第三个或它的变体(见下文)。
每个“M:N”关系都应由其自己的联结表表示。 OTOH，“1:N”关系不需要额外的表 - 只需要表中“N”一侧的适当外键。
如果我对你的描述理解正确，第三个选项模拟了公司和个人之间的 1:N 关系。如果有任何机会您想要在它们之间建立 M:N 关系模型，您将有一个联结表:company_person ( company_id, person_id, PK (company_id, person_id) )。
Are there other ways to do it?
有时，继承(又名类别、子类型、泛化层次结构等)可用于减少可能的“相关”组合的数量。简而言之，与 parent 建立关系，然后从该 parent 继承的每个 child 都会自动参与该关系。
举个例子，看看this post .
What are disadvantages / advantages?
以声明方式强制执行约束(包括 FK)比通过触发器强制执行更好(不易出错并且可能性能更高)，这又比在客户端代码中强制执行更好。
选择一个更符合该原则的设计。例如，您的选项 1 和 2 不允许 DBMS 以声明方式强制执行 FK。
Is there a special way how hightraffic sides handle their releationships?
良好的逻辑设计和良好的物理实现是良好性能的唯一坚实基础。很难在糟糕的设计上“补强”性能。
也许，你想看看:
关于性能，请不要猜测! 衡量实际数量的数据。
关于mysql - CRM 关系 MySQL，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13497342/