Mysql 客户关系管理_Mysql_Database Design_Orm_Entity Relationship_Crm

Mysql 客户关系管理

mysql database-design orm

Mysql 客户关系管理,mysql,database-design,orm,entity-relationship,crm,Mysql,Database Design,Orm,Entity Relationship,Crm,我们公司正在开发CRM，现在我们必须决定如何处理关系。这是很重要的一点，因为将会有很多。以后再改变结构根本不酷我知道3种方法可以做到这一点：一个关联表： Table: person +----+-----------+------------+ | id | name | company_id | +----+-----------+------------+ | 42 | luke | 12 | +----+-----------+----------

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

我知道3种方法可以做到这一点：

一个关联表：

Table: person

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

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

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

多个关系表：

Table: person

+----+-----------+------------+
| id | name      | company_id |
+----+-----------+------------+
| 42 | luke      | 12         |
+----+-----------+------------+
| 43 | other guy | 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

所以我的问题是，处理大量关系的最佳方法是什么
还有其他方法吗
缺点/优点是什么
有没有一种特殊的方式来处理他们之间的关系

谢谢你们的帮助，伙计们：）

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

第三个或其变体（见下文）

每个“M:N”关系都应该由它自己的连接表表示。OTOH，“1:N”关系不需要额外的表，只需要在“N”一侧的表中有一个合适的外键

如果我正确理解您的描述，那么第三个选项将模拟公司和个人之间的1:N关系。如果你想在它们之间建立一个M:N关系模型，你会有一个连接表：

company\u-person（company\u-id，person\u-id，PK（company\u-id，person\u-id））

还有其他方法吗

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

举个例子，看一看

缺点/优点是什么

以声明方式强制约束（包括FK）比通过触发器强制约束更好（不太容易出错，可能性能更高），这也比在客户端代码中强制约束更好

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

有没有一种特殊的方式来处理他们之间的关系

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

也许，您想看看：

说到表演，不要猜测测量实际数据量