Database 基于文档的数据库与关系数据库的优缺点

我一直在尝试使用基于文档的数据库（在本例中是CouchDB）来满足一些需求。两项一般要求：

• 实体的CRUD，其中某些字段具有唯一索引
• 电子商务web应用程序，如易趣（）

我开始认为基于文档的数据库不是满足这些需求的最佳选择。此外，我无法想象使用基于文档的数据库（可能我的想象力太有限了）

---

当我试图使用面向文档的数据库来满足这些需求时，您能解释一下，如果我向elm询问pears，那么基于文档的数据库最适合存储文档。LotusNotes是一种常见的实现，Notes电子邮件就是一个例子。对于您正在描述的内容，如电子商务、CRUD等，Realational DBs更适合于存储和检索索引的数据项/元素（而不是文档）。

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

一种思考的方式是想象你没有任何电脑，只有纸质文件。您将如何使用传递的纸片创建高效的业务流程？如何避免瓶颈？如果出了问题怎么办

你应该考虑的另一个角度是最终的一致性，你最终会进入一致的状态，但你可能会在一段时间内不一致。这在RDBMS领域是一种诅咒，但在现实世界中极为常见。典型的交易示例是从银行账户转账。这在现实世界中究竟是如何发生的——通过单个原子交易还是通过不同的银行相互发出贷记和借记通知？当你开支票时会发生什么

让我们看看你的例子：

• 实体的CRUD，其中某些字段具有唯一索引

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

因此，我们需要看看现实世界中的问题，看看我们是否能够对此进行建模。你真的需要它们是独一无二的吗？您的应用程序能否处理具有相同值的多个文档？您需要分配唯一标识符吗？你能果断地做到这一点吗？需要这样做的常见场景是需要唯一的顺序标识符。这在复制环境中很难解决。事实上，如果要求唯一id严格按照创建时间顺序排列，那么如果您立即需要该id，则是不可能的。您至少需要放松其中一个约束

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

---

我不知道该在这里补充什么，因为你在那篇帖子上的最后一句话是说“非常有用！谢谢”。这里概述的方法中是否缺少一些仍然会给您带来问题的东西？我认为Kurt先生的答案非常充分，我添加了一个小增强，可以减少争用。

是否需要规范化数据

• 是：使用关系数据库
• 否：使用文档

---

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

• 产品ID
• 描述
• 单价
• 成衣
• 规格

---

这个Specifications字段实际上包含了对产品技术规格文档的引用。这样，你就可以两全其美了。

我是同舟共济的，我现在很喜欢couchdb，我觉得整个功能风格很棒。但我们什么时候开始在ernest应用程序中使用它们呢。我的意思是，是的，我们都可以开始非常快速地开发应用程序，不需要任何粗糙的东西，所有那些关于正常形式的令人讨厌的障碍都被搁置在一边，而不使用模式。但是，用一句话来说，“我们站在巨人的肩膀上”。使用RDBMS、规范化和使用模式是有充分理由的。我的老甲骨文负责人正在绞尽脑汁地思考没有形式的数据

我对couchdb的主要关注点是复制和版本控制系统的协同工作

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

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

但是我会使用couchdb来处理结构数据吗。我不知道，我非常感谢你在这方面的帮助

---

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

关于CRUD：整个REST范式直接映射到CRUD（反之亦然）。因此，如果您知道可以使用资源（可通过URI识别）和一组基本操作（即CRUD）对您的需求进行建模，那么您可能非常接近基于REST的系统，这是许多面向文档的系统提供的现成系统。

我认识您