为什么多值字段在关系数据库中是个坏主意

Question

在使用Mongodb和Solr / Lucene之后，我开始想知道为什么关系数据库的多值字段（通常）被认为是个坏主意？

我知道关系数据库和normalization的理论基础。然而，在实践中，我遇到了许多用例，我最终使用键值对的元表来补充主表，例如在标记的情况下，我希望我不必进行多个连接查找数据。或者需求突然从支持单个作者变为每篇文章的多个作者。

那么，拥有多值字段有什么缺点，或者供应商选择不支持它，因为它不是SQL标准的一部分？

Answer 1

主要缺点是查询偏差。这种数据库倾向于在设计时考虑到一种特定类型的查询，并且当需要编写其他查询时难以处理。

假设您有学生和课程，并且您对所有这些进行建模，以便您可以在单个表中的单行中说“John Doe采用{法语，代数，关系理论}”和“Jane Doe采取{德语，功能计算，关系理论}“。

这样可以很容易地查询“所有课程后面的内容是什么......”，但试着想象一下，为“所有遵循关系理论的学生都是什么”提供答案。

尝试并想象系统本身应该做的所有事情来提供这样的查询（如果有可能写出来）任何合理执行的机会......

Answer 2

查询偏见假设SQL始终是一种优秀的查询语言。事实上，有时候是一种优秀的查询语言，但它从来都不是一刀切。多值数据库允许您打包多个值并处理“备用透视”查询。 MVDB的示例：UniData http://u2.rocketsoftware.com/products/u2-unidata，OpenInsight http://www.revelation.com/，Reality http://www.northgate-is.com/。还有很多其他的。 他们的查询语言支持您的目标。

Answer 3

我认为这源于这样一个事实：没有简单，标准的方法将集合映射到Relational世界中的列。 mutifield值基本上是一个简单的集合（大多数用例中字符串的数组），很难表示为列。一些RDBMS通过使用分隔符来支持这一点，但是，即使数据库驱动程序允许您在关系数据库中使用多值字段，它也会开始感觉像反模式。像MongoDB这样的数据库依赖于类似JSON的结构来定义数据，集合很容易映射和检索。