数据库设计:到EAV还是不到EAV？

Question

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

1)我是否有主表并将其与次要的名称-值对表相关联？所有属性都位于辅助EAV表中。

• 或者-

2)我是否将最常见的属性(并非所有用户都需要它们，因此我期望有很多空项)放在主表中，并为用户定义属性设置了辅助EAV表？

• 或者-

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

Answer 1

通常情况下，很多空电池都很便宜，不值得正常使用。第二种方法的唯一缺点是，如果您有大量的行(数百万行--可能会出现性能问题)、非常多的列(超过20列--在这些列中查看数据非常烦人)，或者EAV表上有许多独特的约束。

尽管如此，现在已经是2011年了，现在使用带有数据库抽象层的编程框架是有意义的，这样就不会直接设计数据库关系了。类似Django的对象关系映射器允许您关注模型本身，并让最佳实践照顾自己(95%的时间)。这个教程将帮助您入门。Django只适用于web开发数据库建模。对于非web环境，其他框架会更好。

Answer 2

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

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

Answer 3

我在EAV模式方面做了很多工作，它已经很好地达到了目的。我发现空列或动态列(如col1、col2等)在事实发生后很难处理管理，但是查询它们会更容易，因为您不需要太多的联接。

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