如何停止思考“关系”

Question

在工作中，我们最近使用CouchDB (一个面向文档的数据库)启动了一个项目。我一直在努力学习我所有的关系数据库知识。

我想知道你们中的一些人是怎么克服这个障碍的？你是如何停止了人际关系的思考，并开始以文档的方式思考的(我为编造这个词而道歉)。

有什么建议吗？有用的提示？

编辑:如果有什么不同，我们将使用Ruby&CouchPotato连接到数据库。

编辑2:那是为了让我接受一个答案。我想，我选择了帮助我学习最多的那个。然而，我认为没有真正的“正确”答案。

Answer 1

我想，在阅读了几页关于这个主题的文章之后，这一切都取决于你所处理的数据类型。

RDBMSes代表一种自上而下的方法，您作为数据库设计器，断言数据库中所有数据的结构。您定义一个人有第一个、最后一个、中间名和家庭地址等。您可以使用RDBMS强制执行这一点。如果您没有一个人的HomePlanet的列，倒霉的是想成为一个与地球不同的HomePlanet的人；您将不得不在以后的某个日期添加一个列，否则数据不能存储在RDBMS中。大多数程序员在他们的应用程序中都会做出这样的假设，所以这并不是一件愚蠢的事情。定义事物可能是好的。但是，如果将来需要记录其他属性，则必须将它们添加进来。关系模型假定您的数据属性不会发生太大的变化。

使用类似MapReduce (在您的例子中是CouchDB )的“云”类型的数据库不做上述假设，而是查看自下而上的数据。数据是在文档中输入的，文档中可能有任意数量的不同属性。它假设您的数据，根据其定义，它可能具有的属性类型是多种多样的。它说，“我只知道我在数据库Person中有一个HomePlanet属性为"Eternium”的文档，还有一个“LastName勋爵”的FirstName。该模型适用于网页:所有的网页都是文档，但文档的实际内容/标签/密钥差异很大，无法适应DBMS从高到高的严格结构。这就是为什么Google认为MapReduce模型是roxors soxors的原因，因为Google的数据集是如此的多样化，它需要从一开始就建立起歧义，而且由于大量的数据集能够利用并行处理( MapReduce使其变得微不足道)。文档-数据库模型假设您的数据的属性可能/将发生很大的变化，或者与“空白”和大量稀疏填充的列非常不同，如果数据存储在关系数据库中，就可能会发现这些列。虽然您可以使用RDBMS来存储这样的数据，但它很快就会变得丑陋。

那么，要回答您的问题:在查看使用MapReduce范式的数据库时，您根本无法从“关系”的角度思考。因为它实际上没有强制关系。这是一个概念上的驼峰，你只需要克服。

我遇到的一篇很好地比较和对比这两个数据库的好文章是MapReduce:后退一大步，它认为MapReduce范式数据库是技术上的倒退，不如RDBMSes。我不得不不同意作者的论点，并认为数据库设计人员只需根据他/她的情况选择合适的一个。

Answer 2

都是关于数据的。如果您拥有的数据在关系上是最有意义的，那么文档存储可能并不有用。一个典型的基于文档的系统是一个搜索服务器，您有一个庞大的数据集并希望找到一个特定的项/文档，文档是静态的，或者是版本化的。

在归档类型的情况下，文档可能实际上是文档，它们不会改变并且具有非常灵活的结构。将它们的元数据存储在关系数据库中是没有意义的，因为它们都是非常不同的，所以很少有文档可以共享这些标记。基于文档的系统不存储空值。

非关系/文档类数据在非规范化时是有意义的。它不会有太大的变化，或者你不太关心一致性。

如果您的用例很适合关系模型，那么可能不值得将它压缩到文档模型中。

这里有一篇关于非关系数据库的好文章。

另一种思考它的方法是，文档就是一行。关于文档的所有内容都在该行中，并且它是特定于该文档的。行易于拆分，因此缩放更容易。

Answer 3

在CouchDB中，就像Lotus一样，您真的不应该将文档看作类似于一行。

相反，文档是一个关系(表)。

每个文档都有许多行--字段值：

ValueID(PK)  Document ID(FK)   Field Name        Field Value
========================================================
92834756293  MyDocument        First Name        Richard
92834756294  MyDocument        States Lived In   TX
92834756295  MyDocument        States Lived In   KY

每个视图都是一个跨选项卡的查询，它在一个大规模的UNION中选择每个文档的所有内容。

因此，它仍然是关系型的，但不是最直观的，也不是最重要的:良好的数据管理实践。