数据库设计：EAV 还是不EAV？答案

【问题标题】：Database Design: to EAV or not to EAV?数据库设计：EAV 还是不EAV？
【发布时间】：2011-04-09 23:56:47
【问题描述】：

假设我有一个具有许多属性的实体，其中一些是我现在知道的，而另一些则是用户定义的。对此建模的最佳方法是什么？

1) 我是否有一个主表并将其与辅助名称-值对表相关联？所有属性都在辅助 EAV 表中。

或者-

2) 我是否将最常见的属性（并非所有用户都需要它们，所以我希望有很多 NULL 条目）放在主表中，并为用户定义的属性提供辅助 EAV 表？

或者-

3) 其他一些我没有想到的方法？

【问题讨论】：

标签： mysql database database-design

【解决方案1】：

出于效率原因，您可以使用解决方案二，特别是如果您需要经常选择这些数量。如果需要，这些值可能是 EAV 表的“缓存”。您引入了重复但加快了查找速度。

EAV 是解决此问题的好方法，除非您必须在 db 级别执行连接。另一种方法是从关系模型转移到基于 RDF 的模型。

【讨论】：

【解决方案2】：

通常，大量空单元格很便宜，不值得标准化。回到 #2 的唯一缺点是，如果您有大量的行（数百万 - 可能会出现性能问题），大量的列（超过 20 - 只是查看数据很烦人），或者 EAV 表上有许多独特的约束。

话虽如此，现在是 2011 年，现在使用具有数据库抽象层的编程框架是有意义的，这样您就不会直接设计数据库关系。像 Django 的 Object Relational Mapper 这样的东西可以让您专注于模型本身，并让最佳实践自行处理（95% 的时间）。这个tutorial 将帮助您入门。 Django 仅适用于 Web 开发数据库建模。对于非网络环境，其他框架会更好。

【讨论】：

我正在考虑使用 Doctrine，尽管我承认我仍然没有真正完全理解 ORM 的概念。我不明白 ORM 是如何做到的，所以我“不直接设计数据库关系”。我目前正在 MySQL Workbench 中研究这个模型，并通过大量数据分析来了解我的数据关系。 ORM 是如何让我摆脱这些的？

【解决方案3】：

我对 EAV 模式做了很多工作，它已经很好地达到了目的。我发现空列或动态列（如 col1、col2 等）在事后管理起来要困难得多，但查询它们会更容易，因为您不需要那么多连接。

我强烈推荐的一件事是看看像 Mongo DB 这样的选项。它自动处理复杂的动态数据结构。

【讨论】：