代码之家 › 专栏 › 技术社区 › David Archer Chris Spicer

如何克服eav数据库报表的不足?

system-design entity-attribute-value architecture database-design

David Archer Chris Spicer · 技术社区 · 14 年前

sql中实体属性值数据库设计的主要缺点似乎都与能够高效、快速地查询和报告数据有关。由于这些问题以及几乎所有应用程序的查询/报告的通用性,我在这个主题上读到的大多数信息都警告不要实现eav。

我目前正在设计一个系统,其中一个实体的字段在设计/编译时未知,由系统的最终用户定义。eav似乎很适合这个需求,但是由于我读到的问题,我在实现它时犹豫了,因为这个系统也有一些相当重的报告需求。我认为我想出了一个办法来解决这个问题,但我想向SO社区提出这个问题。

考虑到典型的规范化数据库(oltp)仍然不是运行报表的最佳选择,一个好的做法似乎是使用“报表”数据库(olap),将规范化数据库中的数据复制到该数据库中,并对其进行广泛的索引,还可能对其进行非规范化以便于查询。同样的想法可以用来解决eav设计的缺点吗?

我看到的主要缺点是将数据从eav数据库传输到报表的复杂性增加,因为在eav数据库中定义新字段时,您可能最终不得不更改报表数据库中的表。但这几乎是不可能的,而且似乎是一个可以接受的折衷方案,以提高eav设计的灵活性。如果我使用非sql数据存储(即couchdb或类似的存储)作为主数据存储,也会存在这种缺点,因为所有的标准报告工具都希望使用sql后端进行查询。

如果您有一个单独的报告数据库进行查询,那么eav系统的问题是否会消失?

编辑:谢谢你到目前为止的评论。关于我正在开发的系统的一个重要的事情是,我实际上只是在讨论对其中一个实体使用eav,而不是系统中的所有实体。

该系统的整个要点是能够从多个不同的数据源中提取数据,而这些数据是事先不知道的,并对这些数据进行处理,从而得出一些关于某个特定实体的“最知名”数据。所以我处理的每一个“字段”都是多值的,我还需要跟踪每个字段的历史记录。这种规范化的设计最终是每个字段一个表,这使得查询它有点痛苦。

下面是我正在查看的表模式和示例数据(显然与我正在处理的内容不同,但我认为它很好地说明了这一点):

EAV表

Person
-------------------
-  Id - Name      -
-------------------
- 123 - Joe Smith -
-------------------

Person_Value
-------------------------------------------------------------------
- PersonId - Source - Field       - Value         - EffectiveDate -
-------------------------------------------------------------------
-      123 -    CIA - HomeAddress - 123 Cherry Ln -    2010-03-26 -
-      123 -    DMV - HomeAddress - 561 Stoney Rd -    2010-02-15 -
-      123 -    FBI - HomeAddress - 676 Lancas Dr -    2010-03-01 -
-------------------------------------------------------------------

报表

Person_Denormalized
----------------------------------------------------------------------------------------
-  Id - Name      - HomeAddress   - HomeAddress_Confidence - HomeAddress_EffectiveDate - 
----------------------------------------------------------------------------------------
- 123 - Joe Smith - 123 Cherry Ln -                  0.713 -                2010-03-26 -
----------------------------------------------------------------------------------------

规范化设计

Person
-------------------
-  Id - Name      -
-------------------
- 123 - Joe Smith -
-------------------

Person_HomeAddress
------------------------------------------------------
- PersonId - Source - Value         - Effective Date - 
------------------------------------------------------
-      123 -    CIA - 123 Cherry Ln -     2010-03-26 -
-      123 -    DMV - 561 Stoney Rd -     2010-02-15 -
-      123 -    FBI - 676 Lancas Dr -     2010-03-01 -
------------------------------------------------------

这里的“confidence”字段是使用逻辑生成的,使用sql很难(如果有的话)表示,因此除了插入新值之外,我最常用的操作是为所有字段提取一个人的所有数据,以便生成报表表的记录。这实际上是 更容易的 在eav模型中,我可以做一个查询。在规范化设计中,我最终不得不对每个字段执行一个查询,以避免大量笛卡尔产品将它们连接在一起。

4 回复 | 直到 9 年前

Pat 14 年前

简短回答-是的,报告数据库是解决从eav数据模型报告问题的合理方法。

我花了很多年时间研究一个信息管理解决方案,它允许最终用户完全自由地定义自己的数据模型,模式和数据都是使用eav模型存储的。有趣的是,该产品提供了用于满足报告要求的元模式对象(例如,提供对象导航的图形、执行投影的视图等)。这意味着最终用户可以使用与第一次构建数据模型时相同的术语和概念自由定义查询。报告的行为本质上是通过导航这些定义来计算数据集,并将结果交给传统的报告编写工具,就好像它是关系数据一样。

这种方法的一个优点是,将eav模型转换为用户可以使用的模型的相同机制可以重用并应用于报告功能。

Damian Yerrick 9 年前

在这个方案中,首先我们提出了一个系统,允许用户存储任何类型的数据,不管其结构如何,也不管将来的预期用途如何。然后,到了发布报告的时候,我们必须弄清楚我们得到了什么,以及这与我们需要的有什么关系。

既然你清楚地把问题的本质归结为“在这个方案中”,在我看来,eav的问题似乎真的是由于EAV本身。

事实上,想想看:“一个允许用户存储任何类型数据的系统”相当于一个允许用户只定义其relvars的系统。但是系统的哪个部分允许用户定义每个属性的约束?哎呀,eav用户似乎错过了数据管理中一个并不重要的方面,似乎……

Walter Mitty 14 年前

eav的问题并不是由于eav本身。这是由于在设计和构建数据库时没有理解数据需求的真正含义,以及数据必须具有什么样的逻辑结构才能满足这些需求。eav和任何其他允许用户设计自己的数据的系统,都会将此置于脑后。

在这个方案中,首先我们提出了一个系统,允许用户存储任何类型的数据,不管其结构如何,也不管将来的预期用途如何。然后,到了发布报告的时候,我们必须弄清楚我们得到了什么,以及这与我们需要的有什么关系。

祝你好运。

Preston 12 年前

eav没有问题,我花了大量时间从大量的eav数据库查询。任何一个说从eav报告是困难的或不可能的人都有两个问题中的一个,要么他们的eav系统设计得很差,要么他们不知道如何从一个中查询。从eav数据库获得好的可报告数据非常容易,只要您做了几次。不需要报表数据库或任何特殊的东西,只需要几个好的查询。

如果您正在构建一个eav-db,需要花费大量时间来设计它,那么这个设计要么会使您的应用程序成功,要么会破坏您的应用程序,而试图修复或处理一个设计糟糕的应用程序将是一场噩梦。