如何克服EAV数据库报告的缺点？

Question

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

我目前正在设计一个系统，其中一个实体的字段在设计/编译时未知，并且由系统的最终用户定义。EAV 似乎很适合此要求，但由于我读过的问题，我对实施它犹豫不决，因为该系统也有一些相当繁重的报告要求。我 思考 我已经想出了解决这个问题的方法，但想向 SO 社区提出这个问题。

鉴于典型的规范化数据库 (OLTP) 仍然并不总是运行报告的最佳选择，一个好的做法似乎是拥有一个“报告”数据库 (OLAP)，其中规范化数据库中的数据被复制到其中并建立广泛的索引，并且可能会被非规范化以便于查询。是否可以使用相同的想法来解决 EAV 设计的缺点？

我看到的主要缺点是将数据从 EAV 数据库传输到报告的复杂性增加，因为在 EAV 数据库中定义新字段时，您可能最终不得不更改报告数据库中的表。但这几乎是不可能的，而且对于 EAV 设计所提供的灵活性的提高来说，这似乎是一个可以接受的折衷方案。如果我使用非 SQL 数据存储（即CouchDB 或类似）用于主要数据存储，因为所有标准报告工具都期望 SQL 后端进行查询。

如果您有单独的报告数据库用于查询，EAV 系统的问题是否大部分都会消失？

编辑：感谢到目前为止的评论。关于我正在开发的系统，最重要的事情之一是我实际上只是谈论将 EAV 用于其中一个实体，而不是系统中的所有内容。

该系统的整个要点是能够从提前未知的多个不同来源提取数据，并处理数据以得出有关特定实体的一些“最知名”数据。因此，我正在处理的每个“字段”都是多值的，并且我还需要跟踪每个“字段”的历史记录。标准化设计最终是每个字段 1 个表，这使得查询变得有点痛苦。

以下是我正在查看的表架构和示例数据（显然与我正在处理的内容有所不同，但我认为它很好地说明了这一点）：

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 -
------------------------------------------------------

这里的“置信度”字段是使用 SQL 无法轻松表达（如果有的话）的逻辑生成的，因此除了插入新值之外，我最常见的操作是提取有关某个人的所有字段的所有数据，以便我可以生成该人的记录报告表。这实际上是 更轻松 在 EAV 模型中，我可以执行单个查询。在规范化设计中，我最终必须对每个字段执行 1 次查询，以避免大量笛卡尔积将它们连接在一起。

Answer 1

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

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

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

Answer 2

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

由于您明确地将问题的本质归因于“处于该方案中”，因此在我看来，EAV 的问题确实如此 是 由于 EAV 本身。

事实上，仔细想想：“一个允许用户存储任何类型数据的系统”相当于一个允许用户只定义其相关变量的系统。但是该系统的哪一部分允许用户定义每个属性的约束？哎呀，EAV 人群似乎错过了数据管理的一个不那么不重要的方面，看起来......

Answer 3

EAV 的问题并不是由 EAV 本身造成的。这是因为在设计和构建数据库时没有了解数据的真正需求是什么，以及数据必须具有什么逻辑结构才能满足这些需求。EAV 以及任何其他允许用户设计自己的数据的系统都颠覆了这一点。

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

祝你好运。

Answer 4

EAV没有问题我花了相当多的时间从MASSIVE EAV数据库中查询。任何说从 EAV 进行报告很困难或不可能的人都会遇到以下两个问题之一：要么他们的 EAV 系统设计很糟糕，要么他们不明白如何从系统中进行查询。一旦您完成了几次，从 EAV DB 获取良好的可报告数据就变得非常容易。不需要报告数据库或任何特殊的东西，只需一些好的查询即可。

如果您正在构建 EAV DB 并花费大量时间进行设计，那么该设计要么会成就您的应用程序，要么会破坏您的应用程序，并且尝试修复或处理设计不佳的应用程序将是一场噩梦。