database 为什么我应该使用基于文档的数据库而不是关系数据库？

Why should I use document based database instead of relational database?

提问by Bartosz Blimke

Why should I use document based database like CouchDB instead of using relational database. Are there any typical kinds of applications or domains where the document based database is more suitable than the relational database?

为什么我应该使用像 CouchDB 这样的基于文档的数据库而不是使用关系数据库。是否存在基于文档的数据库比关系数据库更适合的典型应用程序或领域？

回答by max

Probably you shouldn't :-)

可能你不应该:-)

The second most obvious answer is you should use it if your data isn't relational. This usually manifests itself in having no easy way to describe your data as a set of columns. A good example is a database where you actually store paper documents, e.g. by scanning office mail. The data is the scanned PDF and you have some meta data which always exists (scanned at, scanned by, type of document) and lots of possible metadata fields which exists sometime (customer number, supplier number, order number, keep on file until, OCRed fulltext, etc). Usually you do not know in advance which metadata fields you will add within the next two years. Things like CouchDB work much nicer for that kind of data than relational databases.

第二个最明显的答案是，如果您的数据不是关系数据，您应该使用它。这通常表现为没有简单的方法将您的数据描述为一组列。一个很好的例子是您实际存储纸质文档的数据库，例如通过扫描办公室邮件。数据是扫描的 PDF，您有一些始终存在的元数据（扫描位置、扫描者、文档类型）和许多可能存在的元数据字段（客户编号、供应商编号、订单编号、存档直到， OCRed 全文等）。通常，您事先并不知道将在未来两年内添加哪些元数据字段。像 CouchDB 这样的东西比关系数据库更适合处理这类数据。

I also personally love the fact that I don't need any client libraries for CouchDB except an HTTP client, which is nowadays included in nearly every programming language.

我个人也喜欢这样一个事实：除了 HTTP 客户端之外，我不需要任何 CouchDB 客户端库，现在几乎所有编程语言都包含它。

The probably least obvious answer: If you feel no pain using a RDBMS, stay with it. If you always have to work around your RDBMS to get your job done, a document oriented database might be worth a look.

可能最不明显的答案是：如果您在使用 RDBMS 时不感到痛苦，请继续使用它。如果您总是需要围绕 RDBMS 来完成工作，那么面向文档的数据库可能值得一看。

For a more elaborate list check this posting of Richard Jones.

有关更详细的列表，请查看Richard Jones 的这篇帖子。

回答by S.Lott

CouchDB (from their website)

CouchDB（来自他们的网站）

• A document database server, accessible via a RESTful JSON API. Generally, relational databases aren't simply accessed via REST services, but require a much more complex SQL API. Often these API's (JDBC, ODBC, etc.) are quite complex. REST is quite simple.

• Ad-hoc and schema-free with a flat address space. Relational databases have complex, fixed schema. You define tables, columns, indexes, sequences, views and other stuff. Couch doesn't require this level of complex, expensive, fragile advanced planning.

• Distributed, featuring robust, incremental replication with bi-directional conflict detection and management. Some SQL commercial products offer this. Because of the SQL API and the fixed schemas, this is complex, difficult and expensive. For Couch, it appears simple and inexpensive.

• Query-able and index-able, featuring a table oriented reporting engine that uses Javascript as a query language. So does SQL and relational databases. Nothing new here.

• 一个文档数据库服务器，可通过 RESTful JSON API 访问。通常，关系数据库不是简单地通过 REST 服务访问，而是需要更复杂的 SQL API。通常，这些 API（JDBC、ODBC 等）非常复杂。REST 非常简单。

• 具有平面地址空间的临时和无模式。关系数据库具有复杂的固定模式。您定义表、列、索引、序列、视图和其他内容。Couch 不需要这种复杂、昂贵、脆弱的高级计划。

• 分布式，具有强大的增量复制功能，具有双向冲突检测和管理功能。一些 SQL 商业产品提供此功能。由于 SQL API 和固定模式，这是复杂、困难和昂贵的。对于 Couch 来说，它看起来既简单又便宜。

• 可查询和可索引，具有使用 Javascript 作为查询语言的面向表的报告引擎。SQL 和关系数据库也是如此。这里没有什么新鲜事。

So. Why CouchDB?

所以。为什么是 CouchDB？

• REST is simpler than JDBC or ODBC.
• No Schema is simpler than Schema.
• Distributed in a way that appears simple and inexpensive.

• REST 比 JDBC 或 ODBC 简单。
• 没有 Schema 比 Schema 更简单。
• 以看似简单且廉价的方式分发。

回答by daonb

For stupidly storing and serving other-servers-data.

愚蠢地存储和服务其他服务器数据。

In the last couple of weeks I've been playing with a lifestream app that polls my feeds (delicious, flickr, github, twitter...) and stores them in couchdb. The beauty of couchdb is that it lets me keep the original data in its original structure with no overhead. I added a 'class' field to each document, storing the source server, and wrote a javascript render class for each source.

在过去的几周里，我一直在玩一个生命流应用程序，它轮询我的提要（delicious、flickr、github、twitter...）并将它们存储在 couchdb 中。couchdb 的美妙之处在于它让我可以在没有开销的情况下将原始数据保留在其原始结构中。我为每个文档添加了一个“类”字段，存储源服务器，并为每个源编写了一个 javascript 渲染类。

Generalizing, whenever your server communicates with another server a schema-less storage is best as you have no control over the schema. As a bonus, couchdb uses the native protocols of servers and clients - JSON for representation and HTTP REST for transport.

概括地说，每当您的服务器与另一台服务器通信时，无模式存储是最好的，因为您无法控制模式。作为奖励，couchdb 使用服务器和客户端的本机协议 - JSON 表示和 HTTP REST 传输。

回答by pixelcort

Rapid application development comes to mind.

我想到了快速应用程序开发。

When I am constantly evolving my schema, I am constantly frustrated by having to maintain the schema in MySQL/SQLite. While I've not done too much with CouchDB yet, I do like how simple it is to evolve the schema during the RAD process.

当我不断改进我的架构时，我经常因不得不在 MySQL/SQLite 中维护架构而感到沮丧。虽然我还没有对 CouchDB 做太多工作，但我确实喜欢在 RAD 过程中改进架构是多么简单。

A case where you might not want to use a non-relational database is when you have a lot of many-to-many relationships; I've yet to get my head around how to create good MapReduce functions around these kinds of relationships, particularly if you need to have metadata in the joining relationship. I'm not sure, but I don't think CouchDB Map functions can call their own queries on the database, since that could potentially cause infinite loops.

您可能不想使用非关系数据库的一种情况是，当您有很多多对多关系时；我还没有弄清楚如何围绕这些类型的关系创建好的 MapReduce 函数，特别是如果您需要在连接关系中使用元数据。我不确定，但我不认为 CouchDB Map 函数可以在数据库上调用自己的查询，因为这可能会导致无限循环。

回答by smdelfin

Use a document-based database when you do not need to store data in tables with uniform sized fields for each record. Instead, you have a need to store each record as a document that has certain characteristics. Any number of fields of any length can be dynamically added to a document at any time without the need to "modify the table" first. Fields in document-based can also contain multiple pieces of data.

当您不需要将数据存储在每个记录具有统一大小字段的表中时，请使用基于文档的数据库。相反，您需要将每条记录存储为具有某些特征的文档。可以随时动态地将任意数量的任意长度的字段添加到文档中，而无需先“修改表”。基于文档的字段也可以包含多条数据。

回答by MitchB

To elaborate on smdelfin: flexibility. You can store data in any structure (being unstructured and all) and every document could be completely different. CouchDB specifically is useful because with their "view" indexes, you can filter out specific documents and query just that view when you want those subsets of your database.

详细说明 smdelfin：灵活性。您可以以任何结构（非结构化和所有结构）存储数据，并且每个文档都可以完全不同。CouchDB 特别有用，因为通过它们的“视图”索引，您可以过滤掉特定文档并在需要数据库的这些子集时仅查询该视图。

My biggest winning point of document databases that store data in JSON format: this is the native format for JavaScript. Therefore, JavaScript web applications work incredibly-well with CouchDB. I recently made a web app that utilizes CouchDB and it's rocket fast while also able to handle a constantly-varying data structure.

我以 JSON 格式存储数据的文档数据库的最大优势：这是 JavaScript 的原生格式。因此，JavaScript Web 应用程序与 CouchDB 一起工作得非常好。我最近制作了一个使用 CouchDB 的 Web 应用程序，它的速度非常快，同时还能够处理不断变化的数据结构。

回答by evidrascu

Document based databases have a big advantage over relational databases as they do not require defining a schema upfront- before being able to enter any data.

基于文档的数据库与关系数据库相比具有很大的优势，因为它们不需要在能够输入任何数据之前预先定义模式。

Also, you should use a document database if you data is not relational and cannot be stored in a table but rather is a set of images, or for example newspaper articles.

此外，如果您的数据不是关系数据并且不能存储在表中，而是一组图像，或者例如报纸文章，那么您应该使用文档数据库。

Another advantage is the easiness to use document based databases in web development. For more in-depth NoSQL database models comarison check this source: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf

另一个优点是易于在 Web 开发中使用基于文档的数据库。如需更深入的 NoSQL 数据库模型，请查看此来源：https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf