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次查询，以避免大量笛卡尔积与它们一起加入。
答案 0 :(得分：6)
在这个方案中，首先我们提出了一个系统，允许用户存储任何类型的数据，无论其结构如何，并且无论将来的用途如何。然后，当得到报告的时候，我们必须弄清楚我们得到了什么，以及它与我们需要的相关。
由于您明确将问题的性质归因于“正在使用此方案”，因此我觉得EAV的问题确实的问题是由于EAV而导致的。
事实上，想一想：“一个允许用户存储任何类型数据的系统”相当于一个允许用户定义他们的relvars的系统。但是该系统的哪个部分允许用户定义每个属性的约束？哎呀，EAV人群似乎已经错过了一个不那么重要的数据管理方面，似乎......
答案 1 :(得分：3)
EAV的问题不是因为EAV。这是由于设计和构建数据库而不了解数据要求到底是什么，以及数据必须具有什么逻辑结构才能满足这些要求。 EAV以及让用户设计自己的数据的任何其他系统都可以解决这个问题。
在这个方案中，首先我们提出了一个系统，允许用户存储任何类型的数据，无论其结构如何，并且无论将来的用途如何。然后，当得到报告的时候，我们必须弄清楚我们得到了什么，以及它与我们需要的相关。
祝你好运。
答案 2 :(得分：2)
简短回答 - 是的，报告数据库是解决EAV数据模型报告问题的合理方法。
我花了很多年时间使用信息管理解决方案，该解决方案允许最终用户完全自由地定义他们自己的数据模型，同时使用EAV模型存储模式和数据。有趣的是，该产品提供了用于满足报告要求的元模式对象（例如，用于提供对象导航的图形，用于执行投影的视图等）。这意味着最终用户可以使用他们在第一个实例中用于构建数据模型的相同术语和概念来自由定义查询。报告行为主要是通过导航这些定义来计算数据集，并将结果交给传统的报告编写工具，就好像它是关系数据一样。
这种方法的优点之一是，将EAV模型转换为用户可以使用的内容的相同机制可以重复使用并应用于报告功能。
答案 3 :(得分：1)
EAV没有问题我花了很多时间从MASSIVE EAV数据库查询。任何说EAV报告困难或不可能的人都有2个问题中的一个，要么他们的EAV系统设计非常糟糕，要么他们不了解如何查询。一旦你完成了几次，就可以很容易地从EAV数据库中获取可靠的报告数据。不需要报告数据库或任何特殊的，只需要一些好的查询。
如果您正在构建一个EAV数据库花费很多时间来设计它，那么设计将会破坏您的应用程序，这将是一个噩梦，试图修复或处理设计不佳的数据库。