0

我们公司正在开发 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         |
+----+-----------+------------+

等等。

  • 所以我的问题是处理大量关系的最佳方式是什么？
  • 还有其他方法吗？
  • 有什么缺点/优点？
  • 高流量的双方如何处理他们的关系有什么特殊的方式吗？

谢谢你们的帮助：）

4

1 回答 1

3

所以我的问题是处理大量关系的最佳方式是什么？

第三个或它的变体（见下文）。

每个“M:N”关系都应该由它自己的联结表来表示。OTOH，“1：N”关系不需要额外的表 - 只需“N”一侧的表中的正确外键即可。

如果我正确理解您的描述，则第三个选项模拟了公司与个人之间的 1:N 关系。如果您想对它们之间的 M:N 关系进行建模，那么您将有一个联结表：company_person ( company_id, person_id, PK (company_id, person_id) )。

还有其他方法吗？

有时，可以使用继承（又名类别、子类型、泛化层次结构等）来减少可能的“相关”组合的数量。简而言之，与父母建立关系，然后从该父母继承的每个孩子都会自动参与该关系。

例如，看看这篇文章。

有什么缺点/优点？

以声明方式强制执行约束（包括 FK）比通过触发器强制执行更好（更不容易出错并且可能更高效），这又比在客户端代码中强制执行更好。

选择更符合该原则的设计。例如，您的选项 1 和 2 不允许 DBMS 以声明方式强制执行 FK。

高流量的双方如何处理他们的关系有什么特殊的方式吗？

良好的逻辑设计和良好的物理实现是良好性能的唯一坚实基础。很难在糟糕的设计之上“巩固”性能。

也许，您想看看：

在性能方面，不要猜测！衡量真实的数据量。

于 2012-11-21T18:36:42.847 回答