数据库设计：EAV还是EAV？

Question

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

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

• 或 -

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

• 或 -

3）我还没有想过其他一些方法？

Answer 1

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

EAV是解决此问题的好方法，除非您必须在数据库级别执行连接。另一种方法是远离关系模型并转向基于RDF的模型。

Answer 2

通常，许多空单元都很便宜，不值得正常化。回到＃2的唯一回归是，如果你有非常多的行（数百万 - 可能出现性能问题），非常多的列（超过大约20 - 只是看到数据很烦人），或者EAV表上有许多独特的限制。

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

Answer 3

我已经完成了很多EAV模式的工作，它已经足够好了。我发现空列或动态列（如col1，col2等）在事后很难处理，但是由于你不需要那么多的连接，因此查询它们会更容易。

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