【问题标题】:Database EAV Pros/Cons and Alternatives数据库 EAV 优点/缺点和替代方案
【发布时间】:2011-01-14 12:26:41
【问题描述】:

我一直在寻找允许用户定义字段和值(允许无限数量)的数据库解决方案。乍一看,EAV 似乎很合适,但读了一些之后我就不确定了。

EAV 的优缺点是什么?

是否有替代数据库方法允许用户定义属性/字段和值?

【问题讨论】:

标签: sql database database-design nosql entity-attribute-value


【解决方案1】:

这不是一个详尽的答案,而只是关于该主题的几点。

由于该问题也被标记为[sql] 标记,所以我要说的是,一般来说,relational databases 并不特别适合使用EAV 模型存储数据。您仍然可以在 SQL 中设计 EAV 模型,但是您将不得不牺牲关系数据库将提供的许多优势。不仅您将无法强制执行参照完整性、对值使用 SQL 数据类型并强制执行强制属性,而且即使是非常基本的查询也会变得难以编写。事实上,为了克服这个限制,一些 EAV 解决方案依赖于数据复制,而不是与相关表连接,正如您可以想象的那样,它有很多缺点。

如果您真的需要无模式设计,“允许无限数量的属性”,您最好的选择可能是使用NoSQL 解决方案。尽管 EAV 相对于关系数据库的弱点也适用于 NoSQL 替代方案,但您将获得使用传统 SQL 数据库难以实现的附加功能。例如,通常 NoSQL 数据存储可以比关系数据库更容易扩展,这仅仅是因为它们旨在解决某种可扩展性问题,并且它们故意放弃了使扩展变得困难的功能。

许多云计算平台(例如 AmazonGoogleMicrosoft 提供的平台)都具有基于 EAV 模型的数据存储,其中任意数量的属性可以与给定实体相关联。如果您正在考虑将应用程序部署到云上,您可能会认为这既是一种业务优势,也是一种技术优势,因为大型供应商之间的激烈竞争正在将价值成本比推到非常高的水平,通过不断提升功能并降低财务和实施成本。

【讨论】:

  • 我看不出 EAV 有什么技术优势:它的构建、查询和插入更复杂,可读性非常低。一个简单而快速的“select * from”变成了一个缓慢的怪物 sql 查询。我什至不是在谈论尝试基于 EAV 模型进行一些报告。
  • @guigui42:感谢您的评论。你说得有道理,但我的回答并非详尽无遗。不过,由于它已被 OP 标记为已接受,因此我已经更新了答案并进行了一些进一步的考虑。
  • 我对“强制参照完整性”部分有点困惑。我正在使用 EAV 并且有很多外键。由于 UNION ALL 和一些将属性映射到存储它们的表(数据类型)的元数据,可以使用多种 SQL 数据类型。您可以通过向实体表添加额外的索引列来大大提高查询速度(如 @987654328 @ 例如)。
  • @mako-taco 很难应用数据库完整性检查!例如,您将如何检查一个属性是否是强制性的而另一个不是。而如果你在 EAV 表中映射关系,那么你就不能创建数据库关系。
【解决方案2】:

是否有替代数据库方法允许用户定义属性/字段和值?

另一种方法是根据用户输入更改数据库架构:例如,当用户想要一个新字段时,然后将相应的列添加到数据库中。

【讨论】:

  • 这样做的缺点是你会有大量的空白字段
  • @ChrisW:在我看来,可行的场景非常有限。
  • 一些数据库支持“稀疏”列(例如 SQL Server),这使得这种方法更可行。
  • 参与过改进此类模型 - 我强烈建议不要为每个新属性添加新列。
  • 这个方法好像不太可行,每个用户都可以有自己的一组字段,而且这些特定组的可能数量很多。
【解决方案3】:

看看 posgtres hstore http://www.postgresql.org/docs/9.0/static/hstore.html 这将完全符合您的要求,没有大多数缺点

【讨论】:

    【解决方案4】:

    Streams Platform 提出了基于Streams实际上是领域模型)、FieldsAssignments的替代方式 实体。

    【讨论】:

      猜你喜欢
      • 2010-12-03
      • 1970-01-01
      • 2011-06-19
      • 2011-08-12
      • 2011-05-02
      • 2010-09-07
      • 1970-01-01
      • 1970-01-01
      • 2011-01-06
      相关资源
      最近更新 更多