我们的数据库基于EAV（实体-属性-值）模型设计。 了解EAV模型的人都知道为了获得灵活性而带来的所有问题。
我问我的客户为什么使用EAV模型（灵活性），他们的回答是：他们的实体随时间变化。 因此，今天他们可能拥有一个带有一些属性的表，但在一个月的时间内，可能会添加一些新属性，或者重命名现有属性。 他们需要生成报告，以便在任何时间段内返回并根据该阶段实体的形状查询数据。
我理解这在传统的关系型模型中是不可行的，但我个人认为EAV是反模式。 是否有其他替代模型能够捕获实体和实例中更改的时间维度？
干杯， Mosh
EAV实现得好与坏之间存在巨大区别；由熟练人员实现的5NF与由一无所知者实现的5NF也有所不同。
第六范式是不可约范式（无法进一步规范化），它消除了许多常见问题，如空值问题，并提供了识别缺失值的最终方法。它是学术和技术上强大的范式。没有产品支持它，也不常用。要正确而一致地实现它，需要实施元数据目录。当然，用于导航它所需的SQL会变得更加繁琐（SQL已经很复杂了），但这可以通过从元数据自动产生SQL来轻松解决。
EAV是6NF的部分集或子集。问题在于，通常它是为某个目的（允许添加列而不必进行DDL更改）而进行的，由不了解6NF且不实现元数据的人实施。关键是，6NF和EAV作为原则和概念提供了实质性的好处和性能增益；但通常情况下，它们没有得到正确实施，因此好处无法得以实现。相当多的EAV实现都非常糟糕，这并不是因为EAV本身不好，而是因为实现很差。
例如，有些人认为从6NF/EAV数据库构造3NF行所需的SQL很复杂：不，它很繁琐但并不复杂。更重要的是，可以提供普通的SQL视图，以便所有用户和报表工具只看到直接的3NF视图，而6NF/EAV问题对他们来说是透明的。最后，所需的SQL可以自动化生成，因此许多人遭受的劳动成本是完全不必要的。
因此，答案实际上是，第六范式作为EAV的先驱和更纯净的形式，是其替代方案。唯一需要注意的是确保正确实现。我有一个大型的6NF数据库，它没有出现人们发布的任何问题，性能良好，客户非常满意（没有进一步工作是完全功能满足的标志）。
我已经在另一个问题中发布了非常详细的答案，该答案也适用于您的问题，您可能会感兴趣。
补充一下@NickLarsen和@PerformanceDBA的答案：
如果您需要跟踪字段名称等历史更改，您可能需要查看类似Slowly Changing Dimensions的内容。我觉得您正在使用EAV来建模动态维度模型（可能是查找列表）。
最简单（也可能是效率最低）的实现方法是在EAV表上包含一个“截至日期”字段，每当发生更改时，插入一个新记录（而不是更新现有记录）并使用当前日期。这意味着您需要修改查询以始终包括或查找“截至日期”，或者如果没有提供，则默认为“现在”。然后，连接到EAV对象的基本实体必须查询EAV表中“截至日期”小于或等于行的“最后更新”日期，并按“截至日期”降序排序的“top 1”。最坏的情况是，如果您需要跟踪给定行的名称（存储在“属性”表中）和值都已更改的最近更改，则可以使用行的“最后修改”将此逻辑链接到值表，以查找该特定日期的适当值。