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

Question

我们的数据库是基于EAV(实体 - 属性 - 值)模型设计的.那些使用EAV模型的人知道为了灵活性而附带的所有垃圾.

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

我理解这对于传统的关系模型是不可行的,但我个人认为EAV是反模式的.是否有其他替代模型使我们能够捕获实体和实例更改的时间维度？

干杯,莫什

Answer 1

忠实或严重的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问题

Answer 2

无论您使用哪种关系模型,跟踪字段名称更改都需要大量元数据,您必须在事务日志或审计表中跟踪这些元数据.不幸的是,在特定日期查询州内的任何一个都非常复杂.如果您的客户端仅在特定时间日期需要状态,但意味着整个状态,而不仅仅是名称更改,您可以复制数据库并将事务日志回滚到所需的特定时间并在新实例上运行查询.如果在指定日期之后添加的实体需要显示在具有旧字段名称的查询中,则您面临着非常大的工程问题.在这种情况下,根据您在问题中提供的信息,

您可以移动到基于文档的数据存储区,但在第二种情况下仍然无法解决问题.对不起,这不是一个真正的答案,但是在遇到类似情况后,客户可能需要一个更加切合实际的报告解决方案或许多愿意为工程设置资金的其他投资者.

当我们遇到这个问题时,我们保持db模式不变并基于时间戳实现实体映射工厂.最后,客户不断更改要求(每周至每月),以确定如何计算汇总字段,并且从未完全满足.

Answer 3

为每个实体描述版本创建一个新表描述，并创建一个附加表来告诉您哪个表是哪个版本。查询系统也应该更新。

我认为创建一个生成表和查询的脚本是最好的选择。