MySQL 架构建议 : Unpredictable Field Additions

Question

问题的一点概述。

假设我有一个名为 TableA 的表，它具有固定属性 PropertyA、PropertyB、PropertyC。这已经足以满足您自己的网站需求，但是您突然有客户想要在您的网站上自定义字段。

ClientA 想要添加 PropertyD 和 PropertyE。ClientB 想要添加 PropertyF 和 PropertyG。

问题是这些客户不想要彼此的字段。现在想象一下，如果您有更多的客户，仅在 TableA 中添加可为空字段的解决方案将很麻烦，并且您最终会得到一张乱七八糟的表格。或者至少我认为是这种情况，请随时纠正我。如果我这样做会更好吗？

现在我想到了两种解决方案。我在问是否有更好的方法来做到这一点，因为我对权衡取舍和他们 future 的表现不太有信心。

建议的解决方案#1

data_id 不完全是外键，但它存储附加到表 A 行的任何相应的客户端属性。使用 client_id 作为属性表和表 A 中存在的唯一外键。

感觉它是某种反模式，但我可以想象这样查询会很容易，但它要求开发人员知道应该从哪个属性表中选择。我不确定很多表是否是一件坏事。

建议的解决方案#2

我相信它更优雅一些，可以根据需要轻松添加更多字段。更不用说这些是我需要的唯一表格。只是为了形象化。我将像这样在属性表中添加请求属性:

Properties
-------------
1 | PropertyD
2 | PropertyE
3 | PropertyF
4 | PropertyG

每当我保存任何数据时，我都会标记所有可用的属性，就像这样。对于这个例子，我想保存一个 ClientA 存储在 id 1 的 Clients 表中。

Property_Mapping
--------------------------------------------------------
property_id | table_a_id | property_value   | client_id
--------------------------------------------------------
1           | 1          | PROPERTY_D_VALUE | 1
2           | 1          | PROPERTY_E_VALUE | 1

我想，这个问题的查询显然可能很复杂，但这更像是一种权衡。我打算将 client_id 放在 property_mapping 上，以防万一客户需要相同的字段。有什么建议吗？

Answer 1

您发现了 Entity-Attribute-Value反模式。对于关系数据库来说，这是一个糟糕的主意。它使您的查询更加复杂，并且需要 4-10 倍的存储空间。

我在 Stack Overflow 上的一个旧答案中介绍了几种替代方案的优缺点:

• How to design a product table for many kinds of product where each product has many parameters

在演示文稿中:

• Extensible Data Modeling with MySQL

作为 EAV 造成的麻烦的一个例子，考虑一下如果您的一位客户说 PropertyD 必须是强制性的(即等同于 NOT NULL)并且 PropertyE 必须是 ，您将如何回应独一无二的。同时，另一个客户说 PropertyG 应该限制为一组有限的值，因此您应该使用 ENUM 数据类型，或者使用允许值表的外键。

但是您不能使用 Properties 表实现这些约束中的任何一个，因为所有属性的所有值都存储在同一列中。

当您使用这种反模式时，您会失去关系数据库的特性，例如数据类型和约束。