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

我一直在试图查看是否可以用基于文档的数据库来完成一些要求，在这种情况下是CouchDB。两个通用要求：实体的一些领域具有独特的指数上基于文档的数据库与关系型数据库的优缺点

电子商务Web应用程序像eBay（better description here）

CRUD。

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

您能否向我解释一下当我尝试使用面向文档的数据库满足这些要求时，我正在从榆树询问梨？

来源

2008-12-03 user2427

“从榆树问梨”=问不可能。（杰森的链接已经死了。） – Dennis 2012-08-21 16:34:28

基于文档的数据库最适合存储文档。 Lotus Notes是一个常用的实现，Notes邮件就是一个例子。对于您所描述的，电子商务，CRUD等，实际数据库更适合存储和检索索引的数据项/元素（与文档相对）。

来源

2008-12-03 14:57:27

我不同意。文档数据库主要不用于存储文档。它用于存储分层的数据片段（JSON或XML）。您可以使用例如MongoDB为嵌套的JSON字段和JSON数组编制索引。您可以将文档（文件）存储在MongoDB（gridfs）中，但是如果您无法使用MongoDB存储文档（文件），MongoDB仍然很有用。我认为应该将MongoDb称为JSON数据库而不是文档数据库。 – Theo 2010-05-19 15:12:58

根据维基百科对“面向文档的数据库”的条目，“...使用XML，YAML或JSON进行信息存储具有类似于面向文档的数据库的优点”，但它们不是同一回事。文档数据库最初是为存储文档而设计的。如果您将它们用于其他数据，则不会像将文档存储在关系数据库中那样获得最佳性能/使用率。这发生了很多。人们在文档数据库中存储关系数据，然后抱怨文档数据库有多糟糕。如果你滥用它们，是的。 – 2010-05-28 16:30:11

维基百科条目http://en.wikipedia.org/wiki/Document-oriented_database已更新，值得一看，以确认面向文档的数据库的确比文档柜实际更多。 – 2010-11-10 16:37:46

您需要考虑如何以面向文档的方式处理应用程序。如果您只是试图复制如何在RDBMS中对问题进行建模，那么您将会失败。您也可能想要做出不同的折衷。（[编辑：不知道这是如何与参数联系起来的，但是：]请记住，CouchDB的设计假设您将有一个可能随时会失败的许多节点的活动集群。您的应用程序如何处理从其中消失的一个数据库节点在它下面？）

想一想的一种方法是想象你没有任何电脑，只是纸质文件。您如何使用传递的纸张创建高效的业务流程？你怎样才能避免瓶颈？如果事情不顺利怎么办？

你应该考虑的另一个角度是最终的一致性，最终会达到一致的状态，但是在某段时间你可能会不一致。这在RDBMS领域是诅咒，但在现实世界中非常普遍。规范交易的例子是从银行账户转账。这在现实世界中是如何发生的 - 通过单个原子交易或通过不同的银行向对方发放信用卡和借记通知？当你写支票时会发生什么？

所以让我们看看你的例子：实体

CRUD与它唯一索引某些字段。

如果我在CouchDB条款中正确理解这一点，那么您希望拥有一组文档，其中某些命名值在所有这些文档中都是唯一的？这种情况通常不受支持，因为文档可能在不同的副本上创建。

所以我们需要看看现实世界的问题，看看我们是否可以建模。你真的需要他们是独一无二的吗？您的应用程序可以使用相同的值处理多个文档吗？你需要分配一个唯一的标识符吗？你能确定地做到这一点吗？在需要这种情况的常见情况下，您需要一个唯一的顺序标识符。在复制的环境中这很难解决。事实上，如果要求唯一身份证件严格按照创建的时间顺序执行，那么不可能如果您需要马上使用身份证件。你需要放松至少其中一个限制。像eBay

电子商务的Web应用程序，我不知道该怎么在这里添加为最近一次所做的那个帖子是说“非常有用！谢谢”的评论。在那里概述的方法中是否存在某些仍然会导致问题的东西？我认为库尔特先生的回答非常充分，我增加了一点可以减少争用的增强功能。

来源

2008-12-03 16:49:00 Kerr

如何使用UUID分配无共享全局唯一标识符？人们通常在文档数据库世界中做到这一点吗？ – 2011-09-27 17:56:18

是否需要规范化数据？

是：使用关系。
否：使用文档。

来源

2008-12-03 16:52:27 dacracot

一种可能性是有一个主要的关系数据库，它存储可以通过它们的ID检索的项目的定义以及用于这些项目的描述和/或规格的文档数据库。例如，你可以有一个关系数据库产品表具有以下字段：

的ProductID
说明
单价
LotSize
规格

这规格字段实际上会包含对具有产品技术规格的文档的引用。这样，你有两全其美。

来源

2010-01-27 03:13:25 pyon

我在同一条船上，此刻我很喜欢couchdb，我认为整个功能风格都很棒。但是，到底什么时候我们开始将它们用于应用程序。我的意思是，是的，我们都可以开始非常快地开发应用程序，所有那些关于常规形式的讨厌挂断都会被遗忘，而不会使用模式。但是，要给出一句“我们站在巨人的肩膀上”。有一个很好的理由使用RDBMS并规范化和使用模式。我的老oracle头正在思考无形式的数据。

我在couchdb上的主要因素是复制的东西和版本控制系统协同工作。

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

到目前为止，我正在考虑将xml文件，配置文件，资源文件流式传输到base64字符串。

但我会用couchdb来获取结构数据吗？我不知道，任何帮助非常赞赏这一点。

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

来源

2010-06-14 10:16:17 WeNeedAnswers

-1

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

来源

2011-12-06 15:35:24 KoW

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

回答

相关问题