客户关系管理公司MySQL

Question

我们公司正在开发一个CRM，我们现在必须决定如何处理这些关系。这是一个很重要的问题，因为会有很多这样的问题。以后再改变结构是很不酷的。

我知道有三种方法可以做到：

一个发布表：

我这样做的方法是创建一个包含所有关系的表。

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         |
+----+-----------+------------+

ect。

• 那么，我的问题是，是否是处理大量关系的最佳方式？
• 还有其他方法吗？
• 缺点/优点是什么？
• 是否有一种特殊的方式，交通方面如何处理他们的关系？

谢谢你们的帮助:)

Answer 1

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

第三种或其变体(见下文)。

每个"M:N“关系都应该用它自己的连接表来表示。OTOH，"1:N“关系不需要额外的表--只是表中"N”旁边的一个正确的外键。

如果我正确理解你的描述，第三种选择在公司和个人之间建立了1:N的关系。如果您想要建模它们之间的M:N关系，那么您将有一个连接表：company_person ( company_id, person_id, PK (company_id, person_id) )。

还有其他方法吗？

有时，继承(又名。范畴、子类型、泛化层次等)可以用来降低可能的“相关”组合的数量。简单地说，与父母建立关系，那么从父母那里继承下来的每一个孩子都会自动参与到这种关系中。

举个例子，看看这个职位。

缺点/优点是什么？

以声明方式强制执行约束(包括FKs)比通过触发器强制执行约束更好(不容易出错，而且可能更有性能)，这也比在客户端代码中强制执行它们更好。

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

是否有一种特殊的方式，交通方面如何处理他们的关系？

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

也许，你会想看看：

• ERwin方法指南
• 用索引卢克！

当涉及到性能时，不要猜测！根据实际的数据量测量。