在工作中，我们最近开始了一个使用 CouchDB(面向文档的数据库)的项目。我一直很难摆脱我所有的关系数据库知识。
我想知道你们中的一些人是如何克服这个障碍的？您是如何停止关系式思考并开始以文件方式思考的(我为编造这个词而道歉)。
有什么建议吗？有帮助的提示？
编辑:如果有任何不同，我们正在使用 Ruby 和 CouchPotato 连接到数据库。
编辑 2:太麻烦我接受答案了。我认为，我选择了对我学习帮助最大的那个。但是，我想没有真正的“正确”答案。
最佳答案
我认为，在仔细阅读了关于这个主题的几页之后，这完全取决于您正在处理的数据类型。
RDBMS 代表了一种自上而下的方法，您，数据库设计者，断言将存在于数据库中的所有数据的结构。您定义一个人有名字、姓氏、中间名和家庭住址等。您可以使用 RDBMS 强制执行此操作。如果你没有关于一个人的 HomePlanet 的专栏，那么希望成为拥有与地球不同的 HomePlanet 的人的运气不好；您必须在以后添加一列，否则数据无法存储在 RDBMS 中。大多数程序员无论如何都会在他们的应用程序中做出这样的假设，所以假设和强制执行这不是一件愚蠢的事情。定义事物可能很好。但是，如果您将来需要记录其他属性，则必须添加它们。关系模型假定您的数据属性不会发生太大变化。
使用 MapReduce 之类的“云”类型数据库，在您的情况下是 CouchDB，不要做出上述假设，而是从下至上查看数据。数据在文档中输入，文档可能具有任意数量的不同属性。根据其定义，它假定您的数据在其可能具有的属性类型方面是多种多样的。它说，“我只知道我在数据库 Person 中有这个文档，它的 HomePlanet 属性为“Eternium”，名字为“Lord Nibbler”，但没有姓氏。”该模型适用于网页:所有网页都是一个文档，但文档的实际内容/标签/键差异很大，以至于您无法将它们放入 DBMS 高高在上的严格结构中。这就是 Google 认为 MapReduce 模型 roxors soxors 的原因，因为 Google 的数据集是如此多样化，它需要从一开始就为模糊性而构建，并且由于海量数据集能够利用并行处理(MapReduce 使之变得微不足道) .文档数据库模型假定您的数据的属性可能/将会发生很大变化，或者因“差距”而变得非常多样化，并且如果数据存储在关系数据库中，人们可能会发现许多稀疏填充的列。虽然您可以使用 RDBMS 来存储这样的数据，但它很快就会变得丑陋。
然后回答您的问题:在查看使用 MapReduce 范例的数据库时，您根本无法“从关系上”思考。因为，它实际上并没有强制关系。这是您必须克服的概念障碍。
我遇到的一篇很好地比较和对比这两个数据库的文章是 MapReduce: A Major Step Back ，它认为 MapReduce 范式数据库是技术上的倒退，不如 RDBMS。我不同意作者的论点，并认为数据库设计者只需根据他/她的情况选择正确的数据库即可。
关于ruby - 如何停止思考 "relationally"，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1043830/