如何停止思考“关系”

Question

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

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

有什么建议吗？有帮助的提示？

编辑：如果它有什么区别，我们使用Ruby & CouchPotato连接到数据库。

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

Answer 1

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

RDBMSes表示一种自上而下的方法，数据库设计人员将声明数据库中存在的所有数据的结构。你定义一个人有第一个，最后一个，中间名和一个家庭住址等，你可以使用RDBMS强制执行此操作。如果你没有一个人的HomePlanet专栏，那么很难运气的人会拥有与地球不同的HomePlanet;您将不得不在以后的日期添加列，或者数据不能存储在RDBMS中。大多数程序员总是在他们的应用程序中做这样的假设，所以这不是一个愚蠢的事情来承担和执行。定义事物可能很好。但是，如果将来需要记录其他属性，则必须添加它们。关系模型假定您的数据属性不会有太大变化。

使用诸如MapReduce之类的“Cloud”类型数据库（在您的情况下为CouchDB）不做上述假设，而是从下往上查看数据。数据输入到文档中，文档可以具有任意数量的不同属性。它假设你的数据，根据其定义，它可能具有的属性类型是多样的。它说：“我只知道我在数据库Person中拥有一个HomePlanet属性为”Eternium“和”Lord Nibbler“的FirstName但没有LastName的文档。这个模型适合网页：所有的网页都是一个文档，但是文档的实际内容/标签/关键字广泛存在，所以您无法将它们纳入数据库管理系统从高处认可的刚性结构中。这就是为什么谷歌认为MapReduce模型成为业内人士的原因，因为谷歌的数据集非常多样化，需要从一开始就模糊不清，而且由于大量数据集能够利用并行处理（MapReduce使得微不足道） 。文档数据库模型假定您的数据的属性可能会/会变化很多，或者由于“间隙”和大量稀疏填充的列（如果数据存储在关系数据库中可能会发现）而变得非常多样。虽然你可以使用RDBMS来存储这样的数据，但它会变得很难看。

要回答你的问题，那么当你看到一个使用MapReduce范例的数据库时，你根本不会想到“关系”。因为它实际上并没有强制关系。这是一个概念性的驼峰，你只需要克服。

---

一个很好的文章中，我遇到了那个比较和对比两个数据库相当不错的MapReduce: A Major Step Back，它认为，MapReduce的范例数据库是一个技术倒退，而且不如RDBMS中。我不得不不同意作者的论文，并认为数据库设计人员只需为他/她的情况选择合适的人。

Answer 2

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

我自己刚听到它，它是有趣的，但不知道如何实现，在现实世界中的应用;）

Answer 3

一个可以尝试的事情是得到一份firefox和firebug的副本，并玩地图和减少在javascript中的功能。它们实际上是相当冷静和乐趣，而且似乎是如何把事情CouchDB中

完成的基础这里的乔尔对这个问题的小文章：http://www.joelonsoftware.com/items/2006/08/01.html

Answer 4

它的所有有关的数据。如果您有关系最有意义的数据，则文档存储可能没有用处。一个典型的基于文档的系统是一个搜索服务器，你有一个庞大的数据集，并希望找到一个特定的项目/文档，该文档是静态的或版本化的。

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

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

如果你的用例适合一个关系模型，那么它可能不值得把它压缩到一个文档模型中。

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

另一种考虑它的方式是，一个文档是一排。关于文档的所有内容都在该行中，并且该文档是特定的。行很容易分割，因此缩放比较容易。

Answer 5

在CouchDB中，就像Lotus Notes一样，您不应该将文档视为与行相似。

相反，文档是关系（表）。

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

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 

每个View是一个交叉表查询跨越一个巨大的UNION选择每一个文档中的所有的。

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

Answer 6

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