Question

在工作中，我们最近使用CouchDB（面向文档的数据库）开始了一个项目。我一直很难学习所有关系数据库知识。

我想知道你们有些人克服了这个障碍？你是如何停止在关系上思考并开始在文档上思考的（我为弥补这个词而道歉）。

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

编辑：如果它有所不同，我们正在使用Ruby＆amp; CouchPotato连接数据库。

编辑2 ：所以我很难接受答案。我认为，我选择的是帮助我学习最多的那个。但是，我想，没有真正的“正确”答案。

Answer 1

我认为，在仔细阅读有关此主题的几页之后，这一切都取决于您正在处理的数据类型。

RDBMSes代表一种自上而下的方法，数据库设计者可以在其中断言数据库中存在的所有数据的结构。您可以定义Person具有First，Last，Middle Name和Home Address等。您可以使用RDBMS强制执行此操作。如果你没有一个Person's HomePlanet的专栏，那么艰难的运气想成为拥有与地球不同的HomePlanet的人;您必须在以后添加列，否则数据无法存储在RDBMS中。大多数程序员无论如何都会在他们的应用程序中做出这样的假设，所以这不是一个愚蠢的假设和执行的事情。定义东西可能很好。但是如果您将来需要记录其他属性，则必须将它们添加进去。关系模型假设您的数据属性不会发生太大变化。

使用类似MapReduce之类的“云”类型数据库（在您的情况下为CouchDB）不做出上述假设，而是从自下而上查看数据。数据在文档中输入，文档可以具有任意数量的不同属性。它假设您的数据按其定义在其可能具有的属性类型方面是多种多样的。它说，“我只知道我在数据库Person中有这个文件，其HomePlanet属性为”Eternium“，FirstName为”Lord Nibbler“，但没有LastName。”这个模型适用于网页：所有网页都是一个文档，但文档的实际内容/标记/键变化太大，以至于您无法将它们放入DBMS从高处篡改的刚性结构中。这就是为什么谷歌认为MapReduce模型可以解决方法，因为谷歌的数据集非常多样化，需要从一开始就构建模糊性，并且由于大量数据集能够利用并行处理（MapReduce使得微不足道）。文档 - 数据库模型假设您的数据属性可能/将会发生很大变化，或者由于“间隙”和许多稀疏填充的列（如果数据存储在关系数据库中）可能会发现很多。虽然您可以使用RDBMS来存储这样的数据，但它会很快变得难看。

然后回答你的问题：在查看使用MapReduce范例的数据库时，你根本无法“关联”思考。因为，它实际上并没有强制关系。这是一个概念性的驼峰你只需要克服。

我遇到的一篇很好的文章比较和对比这两个数据库很好MapReduce: A Major Step Back，它认为MapReduce范式数据库是一个技术性的倒退，并且不如RDBMS。我不同意作者的论点，并认为数据库设计师只需根据自己的情况选择合适的人选。

Answer 2

这都是关于数据的。如果您拥有最关联的数据，则文档存储可能没用。典型的基于文档的系统是搜索服务器，您拥有庞大的数据集，并且想要查找特定的项目/文档，文档是静态的或版本化的。

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

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

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

这是一篇关于non relational databases的好文章。

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

Answer 3

在CouchDB中，就像Lotus Notes一样，你真的不应该把Document视为与行类似。

相反，Document是 relation （table）。

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

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 ALL。

所以，它仍然是关系型的，但不是最直观的意义，也不是最重要的意义：良好的数据管理实践。

Answer 4

面向文档的数据库不拒绝关系的概念，它们有时只是让应用程序取消引用链接（CouchDB）甚至直接支持文档之间的关系（MongoDB）。更重要的是DODB是无模式的。在基于表的存储中，可以通过显着的开销实现此属性（请参阅richardtallent的回答），但这里的处理效率更高。从RDBMS切换到DODB时我们真正应该学习的是忘记表格并开始考虑数据。这就是绵羊模拟器所谓的“自下而上”的方法。这是一个不断发展的架构，而不是预定义的Procrustean床。当然，这并不意味着架构应该以任何形式完全放弃。您的应用程序必须解释数据，以某种方式限制其形式 - 这可以通过将文档组织到集合中，通过使用验证方法制作模型来完成 - 但现在这是应用程序的工作。

Answer 5

可能你应该读这个 http://books.couchdb.org/relax/getting-started

我自己刚刚听到它并且它很有趣但不知道如何在现实世界的应用程序中实现它;）

Answer 6

你可以尝试的一件事是获取firefox和firebug的副本，并在javascript中使用 map 和 reduce 函数。它们实际上非常酷和有趣，似乎是如何在CouchDB中完成工作的基础

这是Joel关于这个主题的小文章：http://www.joelonsoftware.com/items/2006/08/01.html

如何停止“关系”思考

6 个答案: