database - 实体属性值 (EAV) 的替代方案？

Question

我们的数据库是基于 EAV(实体-属性-值)模型设计的。那些使用过 EAV 模型的人都知道为了灵 active 而带来的所有废话。

我向我的客户询问了使用 EAV 模型(灵 active )的原因，他们的回答是:他们的实体会随着时间而改变。因此，今天他们可能有一个包含一些属性的表，但在一个月后，可能会添加一些新属性，或者可能会重命名现有属性。他们需要生成报告以返回到任何时间阶段，并根据该阶段实体的形状查询数据。

我知道这对于传统的关系模型是不可行的，但我个人认为 EAV 是反模式。是否有任何其他替代模型使我们能够捕获实体和实例变化的时间维度？

干杯，莫什

Answer 1

EAV 的忠实与否是有区别的； 5NF 由熟练的人或无知的人完成。

第六范式是不可约范式(无法进一步规范化)。它消除了许多常见的问题，例如 The Null Problem，并提供了识别缺失值的 final方法。它是学术和技术上强大的 NF。没有产品支持，也不常用。为了正确和一致地实现，它需要一个要实现的元数据目录。当然，导航它所需的 SQL 变得更加麻烦(SQL 已经很麻烦重新连接)，但是通过从元数据自动生成 SQL 可以轻松克服这一点。

EAV 是 6NF 的部分集或子集。问题是，通常它是出于某种目的(允许添加列而无需进行 DDL 更改)，并且是由不了解 6NF 且未实现元数据的人完成的。关键是，6NF 和 EAV 作为原则和概念提供了实质性的好处，并提高了性能；但通常实现不当， yield 未实现。相当多的 EAV 实现是灾难，不是因为 EAV 不好，而是因为实现很差。

例如。有人认为从 6NF/EAV 数据库构造 3NF 行所需的 SQL 很复杂:不，它很繁琐但并不复杂。更重要的是，可以提供一个普通的SQL VIEW，这样所有用户和报表工具都只能看到直接的3NF VIEW，而6NF/EAV问题对他们来说是透明的。最后，所需的SQL可以自动化，因此很多人所承受的人工成本是完全没有必要的。

所以答案确实是，作为 EAV 之父的第六范式，一种更纯粹的形式，是它的替代品。警告是，确保它正确完成。我有一个大型 6NF 数据库，它没有遇到人们发布的任何问题，它表现出色，客户非常满意(没有进一步的工作是功能完全满意的标志)。

我已经发布了另一个问题的非常详细的答案，该问题也适用于您的问题，您可能会感兴趣。

Other EAV Question