0

创建自定义 CRM 系统时，我在为 MySQL 布局找出正确方法时遇到了困难。系统必须是动态的，即。随着时间的推移，可针对多种新产品进行扩展。每个产品都应该有单独的帐单，每个联系人应该有多个产品。

我应该使用这样的表：

Contacts{ ID }
Product_1{ ID; FK_ID; +Custom columns}
Product_2{ ID; FK_ID; +Custom columns}
Product_3{ ID; FK_ID; +Custom columns}
+ 15 more products (Expanding)

或者我应该使用这样的东西：

Contacts{ ID }
Products{ ID; FK_ID; +100 other columns (expanding)}

第一个示例很容易配置，但随着时间的推移会包含很多表。将联系人绑定到产品也需要另一个表。

最后一个示例将更容易在 PHP 中进行配置，但查看表格会变得一团糟。

还有其他想法吗？两者哪个更快？哪个最“常见”？

我觉得这些解决方案都不是最佳的，必须有更好的方法吗？

4

2 回答 2

1

您可以考虑引入第三个表来存储动态“功能”：

Contacts{ Id; }
Products{ Id; }
ProductFeature{ Id; ProductId; FeatureName, FeatureValue }

这确实使查询变得更加复杂，但具有不需要为每个新产品或功能更改架构的优点

于 2013-10-24T09:38:54.500 回答
1

如果您的产品确实彼此不同，请为每个产品创建一个单独的表：

Product_1{ Product_ID (PK); +Custom columns}
Product_2{ Product_ID (PK); +Custom columns}
...

现在，使用这些表格更进一步：

Product {ID (PK auto increment); Contact_ID (FK), Type_ID (FK)}
Product_Type {Type_ID (PK); Type_Name}

在 Product_Type 中插入与自定义产品表（ 、 等）一样多的Product_1行Product_2。每次创建新的特定产品表时，请在表中添加一行Product_Type。

还要将Product_n.Product_ID外键（而不是自动递增）设置为Product.ID.

这样，您可以通过Product表格或具体通过正确的Product_n表格来引用任何类型的产品。您甚至可以通过查看来判断它是什么类型的产品Product.Type_ID。

如果您想让它完全防弹，您可以将该Type_ID列添加到每个Product_n表中，将其包含在 PK 中（与 一起Product_n.Product_ID）并添加一个检查约束，例如Product_1.Type_ID == 1，Product_2.Type_ID == 2等等。这将确保即使您尝试也不会搞砸两者之间的关系，Product但Product_n老实说，我认为这有点矫枉过正，而且我对“非防弹”版本没有任何问题。

于 2013-10-24T10:31:07.873 回答