基于文档的数据库与关系数据库的优缺点 [英] Pros/cons of document-based databases vs. relational databases

问题描述

我一直在试图看看是否可以使用基于文档的数据库（在这种情况下是CouchDB）完成一些要求。两个一般要求：

I've been trying to see if I can accomplish some requirements with a document based database, in this case CouchDB. Two generic requirements:

• 包含具有唯一索引的字段的实体的CRUD


• 电子商务像eBay这样的网络应用程序（这里更好地描述）。 li>
  

• CRUD of entities with some fields which have unique index on it
• ecommerce web app like eBay (better description here).

我开始认为基于文档的数据库不是解决这些要求的最佳选择。此外，我不能想象一个基于文档的数据库的使用（也许我的想象力太有限）。

And I'm begining to think that a Document-based database isn't the best choice to address these requirements. Furthermore, I can't imagine a use for a Document based database (maybe my imagination is too limited).

如果在我尝试使用面向文档的数据库来满足这些要求时，如果我从榆树询问梨，你能向我解释吗？

Can you explain to me if I am asking pears from an elm when I try to use a Document oriented database for these requirements?

推荐答案

您需要考虑如何以面向文档的方式处理应用程序。如果你只是试图复制如何在RDBMS中建模问题，那么你会失败。还有不同的取舍，你可能想做。 （不知道这是如何绑定到参数，但是：]记住，CouchDB的设计假设你将有一个活跃的群集的许多节点，可能会在任何时候失败。你的应用程序如何处理一个数据库节点消失在它下面？）

You need to think of how you approach the application in a document oriented way. If you simply try to replicate how you would model the problem in an RDBMS then you will fail. There are also different trade-offs that you might want to make. ([ed: not sure how this ties into the argument but:] Remember that CouchDB's design assumes you will have an active cluster of many nodes that could fail at any time. How is your app going to handle one of the database nodes disappearing from under it?)

一个想法是想象你没有任何电脑，只是纸质文件。如何使用传递的纸张创建有效的业务流程？如何避免瓶颈？如果出现问题怎么办？

One way to think about it is to imagine you didn't have any computers, just paper documents. How would you create an efficient business process using bits of paper being passed around? How can you avoid bottlenecks? What if something goes wrong?

您应该考虑的另一个角度是最终的一致性，最终将达到一致的状态，但是您可能会在一段时间时间。这是RDBMS土地中的麻烦，但在现实世界中极为常见。规范交易的例子是从银行帐户转移资金。这在现实世界中是如何发生的 - 通过单一原子交易或通过不同的银行相互发放信用和借记通知？

Another angle you should think about is eventual consistency, where you will get into a consistent state eventually, but you may be inconsistent for some period of time. This is anathema in RDBMS land, but extremely common in the real world. The canonical transaction example is of transferring money from bank accounts. How does this actually happen in the real world - through a single atomic transactions or through different banks issuing credit and debit notices to each other? What happens when you write a cheque?

这样看看你的例子：

<

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

If I understand this correctly in CouchDB terms, you want to have a collection of documents where some named value is guaranteed to be unique across all those documents? That case isn't generally supportable because documents may be created on different replicas.

因此，我们需要看看现实世界的问题，看看我们是否可以建模。你真的需要他们是独一无二的吗？您的应用程序可以处理具有相同值的多个文档吗？是否需要分配唯一标识符？你能确定地做到这一点吗？需要这种情况的常见场景是您需要唯一的顺序标识符。这在复制环境中很难解决。事实上，如果唯一ID需要严格按照创建的时间顺序，那么它不可能如果你需要立即获得id。

So we need to look at the real world problem and see if we can model that. Do you really need them to be unique? Can your application handle multiple docs with the same value? Do you need to assign a unique identifier? Can you do that deterministically? A common scenario where this is required is where you need a unique sequential identifier. This is tough to solve in a replicated environment. In fact if the unique id is required to be strictly sequential with respect to time created it's impossible if you need the id straight away. You need to relax at least one of those constraints.

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

我不知道在这里添加什么，因为您在该帖子上发表的最后一条评论是非常有用！谢谢。从那里概述的方法有没有什么，仍然导致你的问题吗？我认为Mr Kurt的答案很满，我添加了一些增强，可以减少争用。

I'm not sure what to add here as the last comment you made on that post was to say "very useful! thanks". Was there something missing from the approach outlined there that is still causing you a problem? I thought MrKurt's answer was pretty full and I added a little enhancement that would reduce contention.

这篇关于基于文档的数据库与关系数据库的优缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！