我被要求为应用程序提出逻辑数据模型。我已经确定了所有实体，并使用 ERD 记录了它们。现在，一位同事提出了一些我不同意的更改建议，我需要理由支持和反对我和他的方法，以便能够提出问题的最佳解决方案。
所以基本上讨论是这样的：我有一个这样的实体：
The_Entity
我的同事建议做
The_Entity
属性
所以基本上也将属性建模为实体。
我认为我的方法在语义上更有意义，但它也更加静态（在实现中，添加属性需要向表中添加列）。你对此有什么看法？
同意已经给出的答案。
针对 EAV 的最明显案例是当存在涉及您提到的属性的业务规则时。比如说，在您的示例中，“属性 1 和属性 2 不能都长于……字符。”。
如果您使用单个三列表来实现示例，那么实现该业务规则就像在该表上定义单个 CHECK 约束一样简单明了。该规则将简单明了，也可供稍后阅读您的设计的其他人解码，并且在运行时，检查约束将像旋风一样进行。
如果您使用 EAV 方法实现您的示例，则无法以声明方式实现相同的业务规则，因此它将需要（相当多）额外代码，对于以后阅读设计的任何人来说，这将更难以解码，这出错的机会更多，尤其是在事务序列化领域，并且在运行时它可能最终成为性能噩梦，使您的系统像没有腿的狗一样运行。
您还可以询问您的朋友他打算如何在他的设计中包含属性，如果这些属性的值是整数、日期、浮点数、布尔值或 DBMS 必须提供的任何其他类型。（他不能坚持一个表而不产生性能问题，即在读取时必须取消对任何数字的字符串，并在写入时对任何数字进行字符串。这是一个 CPU 占用的噩梦。）
您的朋友“发现”的实际上是DBMS 本身用于记录用户数据库结构的设计。DBMS 目录已经知道这种结构几十年了（当然，除了“V”部分之外，目录是 EA，可以说是没有 V 的 EAV），所以它在任何意义上都不是一个“新”的想法。
所以是的，当他声称通过他的设计可以更容易地调整数据库的结构时，从某种意义上说，他是对的。但在大多数情况下，为提高灵活性付出的代价高得令人望而却步，特别是如果您还考虑到“提高灵活性”的实际附加值（通常低于 EAV 支持者的建议）。
可以接受EAV 方法的典型案例是处理问卷。如果问卷不是真的 99.99% 稳定（随着时间的推移会延长很多），并且适用于“应该如何填写”的“规则”并不多（如果问题 7 的答案是“是”，那么问题 8 必须回答），并且问卷的答案通常在“孤立”中比在“组合”中更多地检查，那么 EAV 的大多数缺点都不适用，并且可以有效地考虑。
您的同事所提倡的称为“实体-属性-值”或 EAV，并且被广泛认为是一种反模式。（谷歌搜索“EAV evil”，你会发现很多例子。）如果你想知道为什么你不应该按照你的同事建议的方式去做，你会很容易找到它。
话虽如此，如果您查看我在 SO 和 DBA.SE 上的回答，您会发现在某些特定情况下，我是 EAV 的罕见支持者，而 EAV 的坏处并不适用。尽管如此，由于我们不知道您的特定型号是否满足这些特殊条件，我认为避免 EAV 是相当安全的。