来自CouchDB文档(https://web.archive.org/web/20090122111651/http://couchdb.apache.org/docs/overview.html):

"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.

所以。为什么CouchDB ?

REST比JDBC或ODBC更简单。 没有图式比图式更简单。 以一种看起来简单而廉价的方式分布。

也许你不应该:-)

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.

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

可能最不明显的答案是:如果使用RDBMS没有痛苦，那么就继续使用它。如果您总是要绕过RDBMS来完成工作，那么面向文档的数据库可能值得一试。

想要更详细的列表，请查看理查德·琼斯的这篇帖子。

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

当我不断地改进我的模式时，我总是因为必须在MySQL/SQLite中维护模式而感到沮丧。虽然我还没有过多地使用CouchDB，但我确实喜欢在RAD过程中演进模式的简单性。

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

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

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

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

如果不需要将数据存储在每个记录具有统一大小字段的表中，则使用基于文档的数据库。相反，您需要将每个记录存储为具有特定特征的文档。任何数量、任何长度的字段都可以在任何时候动态添加到文档中，而不需要首先“修改表”。基于文档的字段也可以包含多个数据。

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

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

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

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

另一个优点是易于在web开发中使用基于文档的数据库。 要了解更多深入的NoSQL数据库模型比较，请查看这个来源:https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf

一个原因是对不一定具有相同结构/模式的JSON(或其他自描述格式)文档提供快速全文搜索。

视情况而定。

是的，这是一个用例。是的，这也是一种开发者体验。是的，要输入的数据的性质很重要(高度可预测、正交、合理、易于规范化，或者不太可能以任何有意义的方式规范化/组织)。是的，一个记录/对象与另一个记录/对象的关系(如果有的话)很重要。是的，你需要如何分析数据很重要。是的，所支持的应用程序的性质很重要(在应用程序中如何使用数据)。

是的，如果一个记录/文档的结构(模式)必须快速更改，或者字段本身对于每个记录/文档必须不是强制性的，那么这就很重要

是的，如果您有大量的数据要存储，并且希望减少检索时间，这很重要。规范化数据(许多独立的、不同的表中的数据)往往需要以某种方式放在一起(连接、子查询等)以返回有用的结果。只要返回一些文档或集合(带有一些过滤)，就可以更快地返回相同的结果。

哦，是的，为了让新的世界秩序得到认可……是的，那些学习JavaScript或Python作为第一门编程语言的人很高兴不用再背负SQL的负担。例如，MongoDB将数据存储为BSON，对于那些只关心获取他们想要的数据的人来说，BSON实际上看起来像JSON——没有模式，只是存储/获取数据，然后继续做下一件事。

Frankly, it matters which one you learned first. If you learned SQL first, then there is a place for everything and everything in its place. You do not mind defining/altering a schema because it makes know your data very well. In fact, some people prefer SQL because the enjoy the feeling of control. The do not mind knowing another domain specific language because of the power it gives to the user. Since SQL has been around since the 70s, it is basically the old school business way of doing things.

使用SQL RDBMS的成本是计划和修改模式的时间(必要时进行分区)、计划表大小和可伸缩性的时间(集群)、学习与数据库的接口以及将记录转换为编程语言数据结构(ORM或其他)。

然而，当涉及到分析数据和提出复杂问题时，SQL是非常有效的。如果您需要的不仅仅是简单的存储和检索需求(包括少量的分析)，那么SQL可以让您走在游戏的前面。

然而，规范化的SQL数据库作为应用程序的整体并不一定适合应用程序的所有数据需求。应用程序(web或其他)的某些方面可能不是业务持续关注的中心和核心。

如果您希望为您的财务记录(支付、购买等)提供一个可靠的、符合ACID的事务(带回滚)记录系统——就像如果您是一家银行——那么无论文档数据库有多好，我都将使用SQL。然而，UI中的一些繁琐的小部件甚至可能不会触及客户记录/业务事务。为什么要有这样的模式呢?

实际上，这就是核心UI web开发人员的观点。他们可以证明文档数据库可以简化开发，但不能使您的业务事务符合ACID。他们获得的经验越多，就越会认识到文档数据库的便利只是一种便利。

我敢肯定，就在我输入这篇文章的时候，有人说XX文档DB现在有兼容ACID的事务，但它有SQL吗?最终，那些希望对所有内容都使用文档db的人将找到实现它的方法——这可能意味着集合和文档将有更多约束，并且它开始转变为模式的——GASP——形式。

Look, with things like REST and GraphQL APIs, you never know where you might be getting data from. You cannot predict or plan the form of all data ahead of time. In cases like these (say, interfacing with the Amazon Web Services APIs), then a document database makes good sense. You do not want to normalize that much data. You just want to access, filter it, and do basic stuff to satisfy the needs of your application. Dumping this data into an SQL database could be a waste of time. Every time AWS updates a service with new data, you might have to change your code and schema to accommodate it. ACKKK! Just store it in collections and documents already!

上面的AWS API示例不涉及事务。如果需要保留一些API信息，就不需要一堆表。不幸的是，有些人试图让每个场景都适合这个用例，但他们错了!

更进一步说，考虑到人们可能从AWS API中摄取的数据量，存储在集合和文档中的分片和集群数据要比分区和集群SQL数据库简单得多。如果您在操作部门工作，那么文档数据库最终会更容易管理。

因此，虽然我喜欢这里的许多答案，但许多人似乎为自己的阵营进行了辩护，并且/或只是简单地解释了文档数据库可能比基于模式的正交SQL数据库更适合的场景。

经验法则:

如果它是核心和关键的业务运作和 持续经营(CRUD, ACID，事务)，SQL。 如果只是为了处理海量数据而进行的处理 应用程序和UI，文档/ NoSQL数据库。