我们公司正在开发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 |
+----+-----------+------------+
等等。
- 所以我的问题是处理大量关系的最佳方式是什么
- 还有其他方法吗
- 缺点/优点是什么
- 有没有一种特殊的方式来处理他们之间的关系
谢谢你们的帮助，伙计们：)
所以我的问题是处理大量关系的最佳方式是什么？
第三个或其变体(见下文)。
每个"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。
有没有一种特殊的方式来处理他们的关系？
良好的逻辑设计和良好的物理实现是获得良好性能的唯一坚实基础。很难在糟糕的设计基础上"强加"性能。
也许，你想看看：
- ERwin方法指南
- 使用索引，卢克
说到性能，不要猜测测量实际数据量。