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

Pros/cons of document-based databases vs. relational databases

提问by user2427

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

我一直在尝试查看是否可以使用基于文档的数据库（在本例中为 CouchDB）来满足某些要求。两个通用要求：

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

• 某些字段具有唯一索引的实体的 CRUD
• 像 eBay 这样的电子商务网络应用程序（这里有更好的描述）。

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 elmwhen I try to use a Document oriented database for these requirements?

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

回答by Kerr

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?)

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

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?

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

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?

您应该考虑的另一个角度是最终一致性，最终您将进入一致状态，但您可能会在一段时间内不一致。这在 RDBMS 领域是令人厌恶的，但在现实世界中却极为普遍。规范的交易示例是从银行账户转账。这在现实世界中是如何发生的——通过单一的原子交易还是通过不同的银行相互发出贷记和借记通知？写支票时会发生什么？

So lets look at your examples:

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

• CRUD of entities with some fields with unique index on it.

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

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.

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

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 ifyou need the id straight away. You need to relax at least one of those constraints.

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

• ecommerce web app like ebay

• 电子商务网络应用程序，如 ebay

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.

我不知道要在这里添加什么，因为您对该帖子的最后一条评论是说“非常有用！谢谢”。那里概述的方法中是否遗漏了一些仍然给您带来问题的东西？我认为 MrKurt 的回答非常完整，我添加了一些可以减少争用的增强功能。

回答by dacracot

Is there a need to normalize the data?

是否需要对数据进行规范化？

• Yes: Use relational.
• No: Use document.

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

回答by WeNeedAnswers

I am in the same boat, I am loving couchdb at the moment, and I think that the whole functional style is great. But when exactly do we start to use them in ernest for applications. I mean, yes we can all start to develop applications extremely quickly, cruft free with all those nasty hang-ups about normal form being left in the wayside and not using schemas. But, to coin a phrase "we are standing on the shoulders of giants". There is a good reason to use RDBMS and to normalise and to use schemas. My old oracle head is reeling thinking about data without form.

我也是一样，我现在很喜欢couchdb，我觉得整个功能风格都很棒。但是我们什么时候开始在 ernest 中将它们用于应用程序。我的意思是，是的，我们都可以非常快速地开始开发应用程序，免除所有那些关于将标准形式搁置一旁而不使用模式的令人讨厌的问题。但是，造句“我们站在巨人的肩膀上”。使用 RDBMS 以及规范化和使用模式是有充分理由的。我的旧预言机负责人正在思考没有形式的数据。

My main wow factor on couchdb is the replication stuff and the versioning system working in tandem.

我在 couchdb 上的主要惊喜因素是复制内容和协同工作的版本控制系统。

I have been racking my brain for the last month trying to grok the storage mechanisms of couchdb, apparently it uses B trees but doesn't store data based on normal form. Does this mean that it is really really smart and realises that bits of data are replicated so lets just make a pointer to this B tree entry?

上个月我一直在绞尽脑汁尝试了解couchdb的存储机制，显然它使用B树但不存储基于范式的数据。这是否意味着它真的非常聪明并且意识到数据位被复制，所以让我们创建一个指向这个 B 树条目的指针？

So far I am thinking of xml documents, config files, resource files streamed to base64 strings.

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

But would I use couchdb for structural data. I don't know, any help greatly appreciated on this.

但是我会使用 couchdb 来获取结构数据吗？我不知道，任何帮助都非常感谢。

Might be useful in storing RDF data or even free form text.

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

回答by pyon

A possibility is to have a main relational database that stores definitions of items that can be retrieved by their IDs, and a document database for the descriptions and/or specifications of those items. For example, you could have a relational database with a Products table with the following fields:

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

• ProductID
• Description
• UnitPrice
• LotSize
• Specifications

• 产品编号
• 描述
• 单价
• 批量
• 规格

And that Specifications field would actually contain a reference to a document with the technical specifications of the product. This way, you have the best of both worlds.

并且该规范字段实际上将包含对具有产品技术规范的文档的引用。这样，您就可以两全其美。

回答by Jim Anderson

Document based DBs are best suiting for storing, well, documents. Lotus Notes is a common implementation and Notes email is an example. For what you are describing, eCommerce, CRUD, etc., realtional DBs are better designed for storage and retrieval of data items/elements that are indexed (as opposed to documents).

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

回答by KoW

Re CRUD: the whole REST paradigm maps directly to CRUD (or vice versa). So if you know that you can model your requirements with resources (identifiable via URIs) and a basic set of operations (namely CRUD), you may be very near to a REST-based system, which quite a few document-oriented systems provide out of the box.

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