78

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

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

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

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

4

6 回答 6

37

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?

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?

So lets look at your examples:

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

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.

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.

  • ecommerce web app like 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.

于 2008-12-03T16:49:00.950 回答
13

Is there a need to normalize the data?

  • Yes: Use relational.
  • No: Use document.
于 2008-12-03T16:52:27.543 回答
8

我在同一条船上，我现在喜欢couchdb，我认为整个功能风格很棒。但是我们究竟什么时候开始在 ernest 中将它们用于应用程序。我的意思是，是的，我们都可以非常快速地开始开发应用程序，摆脱所有那些关于正常形式被搁置而不使用模式的讨厌挂断。但是，要造句“我们站在巨人的肩膀上”。使用 RDBMS 以及规范化和使用模式是有充分理由的。我以前的预言机头脑正在思考没有形式的数据。

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

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

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

但是我会使用 couchdb 来获取结构数据吗？我不知道，对此非常感谢。

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

于 2010-06-14T10:16:17.880 回答
6

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

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

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

于 2010-01-27T03:13:25.130 回答
4

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

于 2008-12-03T14:57:27.837 回答
2

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

于 2011-12-06T15:35:24.103 回答