基于文档的数据库与关系数据库的利弊

基于文档的数据库最适合存储文档。LotusNotes 是一种常见的实现，Notes 电子邮件就是一个例子。对于您所描述的电子商务、 CRUD 等，实际数据库更适合于存储和检索被索引的数据项/元素(相对于文档而言)。

您需要考虑如何以面向文档的方式处理应用程序。如果您只是试图复制如何在 RDBMS 中建模问题，那么您将失败。你可能想要做出不同的权衡。([ ed: 不确定这与参数有什么联系，但是: ]请记住，CouchDB 的设计假设您将拥有一个由许多节点组成的活动集群，这些节点可能在任何时候失败。您的应用程序将如何处理从它下面消失的数据库节点?)

思考这个问题的一种方法是想象你没有任何计算机，只有纸质文档。你将如何创建一个有效的业务流程，使用位的纸张传递？如何避免瓶颈？如果出了问题怎么办？

另一个你应该考虑的角度是最终一致性，在那里你最终会进入一个一致的状态，但是你可能会在一段时间内不一致。这在 RDBMS 领域是一个诅咒，但在现实世界中却非常普遍。规范事务的例子是从银行账户转账。在现实世界中，通过单一的原子交易或通过不同的银行相互发出信用和借记通知，这种情况实际上是如何发生的呢？你开支票的时候会发生什么？

让我们看看你的例子:

• 带有唯一索引的字段的实体的 CRUD。

如果我在 CouchDB 术语中正确地理解了这一点，那么您希望拥有一个文档集合，其中某些命名值在所有这些文档中保证是唯一的？这种情况通常是不可支持的，因为文档可能是在不同的副本上创建的。

所以我们需要看看现实世界的问题，看看我们是否可以建模。你真的需要他们独一无二吗？您的应用程序能够处理具有相同值的多个文档吗？你需要指派唯一标识符吗？你能确定地做到吗？需要这样做的一个常见场景是，您需要一个唯一的顺序标识符。在复制的环境中很难解决这个问题。事实上，如果唯一的 id 需要严格按照创建的时间顺序排列，那么 如果不可能立刻就需要 id。你至少需要放松其中一个限制。

• 像 ebay 这样的电子商务网络应用程序

我不知道该在这里补充什么，因为你在那篇文章的最后一条评论是说: “非常有用！谢谢。”。这里概述的方法是否缺少了什么东西，仍然给您带来问题？我认为库尔特先生的回答相当全面，我添加了一个小的增强，可以减少争论。

是否需要将数据标准化？

• 是的: 使用关系。
• 使用文件。

一种可能的方法是，设置一个主关系数据库，存储可以通过 ID 检索的项目定义，以及一个文档数据库，用于描述和/或说明这些项目。例如，您可以有一个关系数据库，其中的 Products 表包含以下字段:

• 产品编号
• 描述
• UnitPrice
• 批量生产
• 规格

而规格说明字段实际上将包含对具有产品技术规格的文档的引用。这样的话，你就两全其美了。

我也是这样，我现在很喜欢 Couchdb，我觉得整个功能风格很棒。但是我们什么时候开始在应用程序中使用它们呢。我的意思是，是的，我们都可以开始极其迅速地开发应用程序，摆脱所有那些关于正常形式被抛在一边、不使用模式的讨厌的障碍。但是，用一句话来说就是“我们是站在巨人的肩膀上”。有充分的理由使用 RDBMS、规范化和使用模式。我以前的预言家正在思考没有形式的数据。

我对 couchdb 的主要惊叹是复制工具和版本控制系统的协同工作。

上个月我一直在绞尽脑汁想弄明白 couchdb 的存储机制，显然它使用 B 树，但不以正常形式存储数据。这是否意味着它真的非常聪明，并且意识到数据位是被复制的，所以让我们只做一个指向这个 B 树条目的指针？

到目前为止，我考虑的是流到 base64字符串的 xml 文档、配置文件和资源文件。

但是我会使用 Couchdb 来获得结构数据吗? 我不知道，这方面的任何帮助我都非常感激。

在存储 RDF 数据甚至自由格式文本时可能很有用。

Re CRUD: 整个 REST 范例直接映射到 CRUD (反之亦然)。因此，如果您知道您可以使用资源(通过 URI 可以识别)和一组基本操作(即 CRUD)来建模您的需求，那么您可能非常接近于基于 REST 的系统，很多面向文档的系统都提供了开箱即用的系统。