我们的数据库是基于EAV（实体-属性-值）模型设计的。那些使用过 EAV 模型的人都知道为了灵活性而带来的所有废话。
我问我的客户为什么使用EAV模型（灵活性），他们的回答是：他们的实体随着时间的推移而改变。因此，今天他们可能有一个包含一些属性的表，但一个月后，可能会添加一些新属性，或者可能会重命名现有属性。他们需要生成报告以及时返回到任何阶段，并根据该阶段实体的形状查询数据。
我知道这对于传统的关系模型来说是不可行的，但我个人认为 EAV 是反模式。是否有任何其他替代模型使我们能够捕获实体和实例变化的时间维度？
干杯，
莫什
EAV 是否忠实地完成是有区别的； 5NF 由熟练的人或无知的人完成。
第六范式是不可约范式（不可能进一步标准化）。它消除了许多常见问题，例如空问题，并提供了识别缺失值的终极方法。它是学术和技术上强大的 NF。没有产品支持它，并且不常用。为了正确且一致地实施，需要实施元数据目录。当然，导航所需的 SQL 变得更加麻烦（SQL 重新连接已经很麻烦），但是通过从元数据自动生成 SQL 可以轻松克服这一点。
EAV 是 6NF 的部分集或子集。问题是，通常这样做是有目的的（允许添加列而不必进行 DDL 更改），并且由不了解 6NF 且不实现元数据的人完成。关键是，6NF 和 EAV 作为原则和概念提供了实质性的好处，并且性能得到提高；但通常情况下，它没有得到适当的实施，其好处也没有实现。相当多的 EAV 实施都是灾难，不是因为 EAV 不好，而是因为实施很差。
例如。有些人认为从 6NF/EAV 数据库构造 3NF 行所需的 SQL 很复杂：不，它很麻烦但并不复杂。更重要的是，可以提供普通的SQL VIEW，以便所有用户和报表工具只能看到直接的3NF VIEW，而6NF/EAV问题对他们来说是透明的。最后，所需的SQL可以自动化，因此许多人承受的劳动力成本是完全不必要的。
所以答案确实是，第六范式作为 EAV 之父，也是一种更纯粹的形式，是它的替代品。警告是，确保正确完成。我有一个大型 6NF 数据库，它没有遇到人们发布的任何问题，它的性能非常好，客户非常满意（没有进一步的工作是功能完全满意的标志）。
我已经发布了另一个问题的非常详细的答案，该答案也适用于您的问题，您可能对此感兴趣。
其他 EAV 问题 https://stackoverflow.com/questions/4011956/
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
