基于文档的数据库与关系数据库的优缺点
我一直在试图看看是否可以用基于文档的数据库来完成一些要求，在这种情况下是CouchDB。 两个通用要求：
- 某些领域具有唯一索引的实体的CRUD
- 电子商务网站的应用程序，如易趣（ 更好的描述在这里 ）。
而且我开始认为基于文档的数据库不是解决这些需求的最佳select。 此外，我无法想象用于基于文档的数据库（可能我的想象力太有限）。
当我尝试使用面向文档的数据库来满足这些要求时，你能否向我解释一下我是否从榆树那里问梨 ？
您需要考虑如何以面向文档的方式处理应用程序。 如果您只是试图复制如何在RDBMS中对问题进行build模，那么您将失败。 您也可能想要做出不同的折衷。 （[编辑：不知道这是如何绑定到参数，但是：]请记住，CouchDB的devise假设您将有一个可能会在任何时候失败的许多节点的活动集群如何处理从一个数据库节点消失在它下面？）
考虑一下的一种方法是想象你没有任何电脑，只有纸质文件。 你将如何创build一个有效的业务stream程，使用传送的纸张？ 你怎样才能避免瓶颈？ 如果出现错误怎么办？
你应该考虑的另一个angular度是最终的一致性，最终会达到一致的状态，但是在一段时间内你可能会不一致。 这是在RDBMS的土地，但在现实世界中非常普遍的诅咒。 规范交易的例子是从银行账户转账。 这在现实世界中是如何发生的 – 通过单一的primefaces交易或通过不同的银行向对方发放信用和借记通知？ 当你写支票时会发生什么？
所以让我们看看你的例子：
- 具有唯一索引的字段的实体的CRUD。
如果我在CouchDB条款中正确理解了这一点，那么您希望拥有一组文档，其中某些命名值在所有这些文档中保证是唯一的？ 这种情况通常是不可支持的，因为文档可能在不同的副本上创build。
所以我们需要看看现实世界的问题，看看我们是否可以build模。 你真的需要他们是独一无二的吗？ 您的应用程序可以处理多个具有相同值的文档吗？ 你需要分配一个唯一的标识符？ 你能确定吗？ 在需要这种情况的常见情况下，您需要一个唯一的顺序标识符。 在复制的环境中这很难解决。 事实上，如果要求唯一的id是严格按照时间顺序创build的， 那么如果你马上需要id，这是不可能的。 你需要放松至less一个这些限制。
- 电子商务网站的应用程序，如易趣
我不知道要在这里添加什么，因为你对这篇文章的最后一个评论是说“非常有用！谢谢”。 那里列出的方法是否还存在一些问题，但仍然会造成问题？ 我认为库尔特先生的回答非常充分，我加了一点小小的改进来减less争用。
是否需要规范化数据？
- 是：使用关系。
- 否：使用文档。
我在同一条船上，我现在很喜欢couchdb，我认为整个function风格都很棒。 但是到底什么时候我们开始使用它们来应用程序。 我的意思是，我们都可以开始非常迅速地开发应用程序，所有那些关于正常forms的讨厌挂断都被放在一边，而不是使用模式。 但是，要说“我们站在巨人的肩膀上”。 有一个很好的理由使用RDBMS并规范化和使用模式。 我的老oracle头正在思索着没有forms的数据。
我在couchdb上的主要因素是复制内容和版本控制系统协同工作。
上个月，我一直在绞尽脑汁地试图研究couchdb的存储机制，显然它使用B树，但不存储基于正常forms的数据。 这是否意味着它真的很聪明，并意识到数据的位复制，所以让我们只需要指向这个B树条目？
到目前为止，我正在考虑xml文件，configuration文件，资源文件stream到base64string。
但是我会用couchdb来获取结构数据吗？ 我不知道，任何帮助，非常赞赏这一点。
在存储RDF数据甚至自由格式的文本时可能会有用。
一种可能性是有一个主要的关系数据库存储可以通过它们的ID检索的项目的定义，以及用于这些项目的描述和/或规格的文档数据库。 例如，您可以使用具有以下字段的Products表的关系数据库：
- 产品ID
- 描述
- 单价
- 批量
- 产品规格
并且该规范字段实际上将包含对具有该产品的技术规范的文档的引用。 这样，你有两全其美。
基于文档的数据库最适合存储文档。 Lotus Notes是一个常用的实现，Notes邮件就是一个例子。 对于您所描述的，电子商务，CRUD等，实数DB更好地devise用于存储和检索索引的数据项/元素（而不是文档）。
Re CRUD：整个REST范例直接映射到CRUD（反之亦然）。 因此，如果您知道可以使用资源（可通过URI识别）和一组基本的操作（即CRUD）对您的需求进行build模，那么您可能非常接近基于REST的系统，其中有很多面向文档的系统提供的框。
