我一直试图看看我是否可以使用基于文档的数据库来完成某些要求，在本例中为CouchDB。两个通用要求：
我开始认为基于文档的数据库不是满足这些要求的最佳选择。此外，我无法想象使用基于文档的数据库（也许我的想象力太有限）。
当我尝试使用面向文档的数据库来满足这些要求时，你能解释一下我是从榆树那里问梨吗？
答案 0 :(得分：34)
您需要考虑如何以面向文档的方式处理应用程序。如果您只是尝试复制如何在RDBMS中建模问题，那么您将失败。您可能还想做出不同的权衡。 （[编辑：不确定这与参数有什么关系，但是：]请记住，CouchDB的设计假定您将拥有一个可能随时出现故障的许多节点的活动集群。您的应用程序如何处理其中一个数据库节点从中消失根据它？）
考虑它的一种方法是想象你没有任何计算机，只有纸质文件。如何使用传递的纸张创建有效的业务流程？你怎么能避免瓶颈？如果出现问题怎么办？
你应该考虑的另一个角度是最终的一致性，你最终会进入一致的状态，但是你可能会在一段时间内不一致。这在RDBMS领域是一种诅咒，但在现实世界中极为常见。规范交易的例子是从银行账户转账。这实际上是如何在现实世界中发生的 - 通过单一的原子交易或通过不同的银行相互发出信用卡和借记通知？写支票时会发生什么？
让我们看看你的例子：
如果我在CouchDB术语中正确理解这一点，您希望拥有一组文档，其中某些命名值保证在所有这些文档中是唯一的？这种情况通常不受支持，因为可以在不同的副本上创建文档。
因此，我们需要查看现实世界的问题，看看我们是否可以对其进行建模。你真的需要它们独一无二吗？您的应用程序可以处理具有相同值的多个文档吗？您需要分配唯一标识符吗？你能确定地做到这一点吗？需要这种情况的常见方案是您需要唯一的顺序标识符。在复制环境中很难解决这个问题。事实上，如果要求唯一ID在时间上严格按顺序创建，那么 if 你需要至少放松其中一个限制。
我不确定在这里添加什么，因为您在该帖子上发表的最后一条评论是“非常有用！谢谢”。那里概述的方法是否有什么遗漏仍然会导致您出现问题？我认为库尔特先生的回答非常充实，我添加了一些可以减少争用的增强功能。
答案 1 :(得分：14)
是否需要规范化数据？
答案 2 :(得分：7)
我在同一条船上，此刻我很喜欢couchdb，我认为整个功能风格很棒。但是，我们确实开始在欧内斯特的应用程序中使用它们。我的意思是，是的，我们都可以非常快速地开始开发应用程序，所有那些关于正常形式的令人讨厌的问题被搁置在路边并且不使用模式。但是，用一句话“我们站在巨人的肩膀上”。有充分的理由使用RDBMS并规范化和使用模式。我的老甲骨文正在考虑没有形式的数据。
我在couchdb上的主要惊喜因素是复制内容和版本控制系统协同工作。
上个月我一直在努力研究couchdb的存储机制，显然它使用的是B树，但不存储基于正常形式的数据。这是否意味着它真的非常聪明并且意识到复制了一些数据，所以我们只需要指向这个B树条目？
到目前为止，我正在考虑将xml文档，配置文件，流式传输到base64字符串的资源文件。
但是我会使用couchdb来获取结构数据吗？我不知道，任何帮助都非常感谢。
可能有助于存储RDF数据甚至是自由格式文本。
答案 3 :(得分：4)
一种可能性是拥有一个主关系数据库，用于存储可通过其ID检索的项目的定义，以及一个文档数据库，用于描述这些项目的描述和/或规范。例如，您可以拥有一个带有Products表的关系数据库，其中包含以下字段：
该规范字段实际上包含对具有产品技术规格的文档的引用。这样，你就拥有了两全其美的优势。
答案 4 :(得分：3)
基于文档的数据库最适合存储文档。 Lotus Notes是一种常见的实现，Notes电子邮件就是一个例子。对于您所描述的内容，电子商务，CRUD等，实际数据库更适合存储和检索索引的数据项/元素（而不是文档）。
答案 5 :(得分：0)
Re CRUD：整个REST范例直接映射到CRUD（反之亦然）。因此，如果您知道可以使用资源（可通过URI识别）和一组基本操作（即CRUD）来建模您的需求，那么您可能非常接近基于REST的系统，这是一个面向文档的系统提供的的盒子。