来自CouchDB文档(https://web.archive.org/web/20090122111651/http://couchdb.apache.org/docs/overview.html):
"文档数据库服务器，可通过RESTful JSON API访问。通常，关系数据库不是简单地通过REST服务访问，而是需要更复杂的SQL API。通常这些API (JDBC、ODBC等)相当复杂。REST非常简单。
具有平面地址空间的Ad-hoc和无模式。关系数据库具有复杂的、固定的模式。定义表、列、索引、序列、视图和其他东西。沙发不需要这种复杂、昂贵、脆弱的高级计划。
分布式，具有健壮的增量复制，具有双向冲突检测和管理。一些SQL商业产品提供了这一点。由于SQL API和固定模式，这是复杂、困难和昂贵的。对Couch来说，它看起来简单又便宜。
可查询和可索引，具有面向表的报告引擎，使用Javascript作为查询语言。SQL和关系数据库也是如此。这没什么新鲜的。
所以。为什么CouchDB ?
也许你不应该:-)
我个人还喜欢这样一个事实:除了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应用程序，它的速度非常快，同时还能够处理不断变化的数据结构。
基于文档的数据库比关系数据库有一个很大的优势，因为它们不需要预先定义模式——在能够输入任何数据之前。
此外，如果您的数据不是关系型的，不能存储在表中，而是一组图像，或例如报纸文章，则应该使用文档数据库。
一个原因是在JSON(或其他自描述格式)文档上提供快速全文检索，这些文档不一定具有相同的结构/模式。
视情况而定。
是的，这是一个用例。是的，这也是一种开发者体验。是的，要输入的数据的性质很重要(高度可预测、正交、合理、易于规范化，或者不太可能以任何有意义的方式规范化/组织)。是的，一个记录/对象与另一个记录/对象的关系(如果有的话)很重要。是的，你需要如何分析数据很重要。是的，所支持的应用程序的性质很重要(在应用程序中如何使用数据)。
是的，如果一个记录/文档的结构(模式)必须快速更改，或者字段本身对于每个记录/文档必须不是强制性的，那么这就很重要
是的，如果您有大量的数据要存储，并且希望减少检索时间，这很重要。规范化数据(许多独立的、不同的表中的数据)往往需要以某种方式放在一起(连接、子查询等)以返回有用的结果。只要返回一些文档或集合(带有一些过滤)，就可以更快地返回相同的结果。
哦，是的，为了让新的世界秩序得到认可……是的，那些学习JavaScript或Python作为第一门编程语言的人很高兴不用再背负SQL的负担。例如，MongoDB将数据存储为BSON，对于那些只关心获取他们想要的数据的人来说，BSON实际上看起来像JSON——没有模式，只是存储/获取数据，然后继续做下一件事。
坦白地说，你先学哪一个很重要。如果你是先学习SQL的，那么所有东西都有自己的位置。您不介意定义/更改模式，因为它使您非常了解数据。事实上，有些人更喜欢SQL，因为他们喜欢控制的感觉。他们不介意了解另一种领域特定语言，因为它给用户带来了强大的能力。由于SQL早在70年代就出现了，它基本上是一种老式的商业方式。
使用SQL RDBMS的成本是计划和修改模式的时间(必要时进行分区)、计划表大小和可伸缩性的时间(集群)、学习与数据库的接口以及将记录转换为编程语言数据结构(ORM或其他)。
然而，当涉及到分析数据和提出复杂问题时，SQL是非常有效的。如果您需要的不仅仅是简单的存储和检索需求(包括少量的分析)，那么SQL可以让您走在游戏的前面。
然而，规范化的SQL数据库作为应用程序的整体并不一定适合应用程序的所有数据需求。应用程序(web或其他)的某些方面可能不是业务持续关注的中心和核心。
如果您希望为您的财务记录(支付、购买等)提供一个可靠的、符合ACID的事务(带回滚)记录系统——就像如果您是一家银行——那么无论文档数据库有多好，我都将使用SQL。然而，UI中的一些繁琐的小部件甚至可能不会触及客户记录/业务事务。为什么要有这样的模式呢?
实际上，这就是核心UI web开发人员的观点。他们可以证明文档数据库可以简化开发，但不能使您的业务事务符合ACID。他们获得的经验越多，就越会认识到文档数据库的便利只是一种便利。
我敢肯定，就在我输入这篇文章的时候，有人说XX文档DB现在有兼容ACID的事务，但它有SQL吗?最终，那些希望对所有内容都使用文档db的人将找到实现它的方法——这可能意味着集合和文档将有更多约束，并且它开始转变为模式的——GASP——形式。
看，使用REST和GraphQL api，您永远不知道从哪里获取数据。您无法提前预测或计划所有数据的形式。在这样的情况下(例如，与Amazon Web Services api进行接口)，使用文档数据库是很有意义的。你不希望规范化那么多的数据。您只需要访问、过滤它，并做一些基本的事情来满足应用程序的需要。将这些数据转储到SQL数据库中可能会浪费时间。每次AWS用新数据更新服务时，您可能都必须更改代码和模式以适应新数据。ACKKK !只要把它存储在集合和文档中就可以了!
上面的AWS API示例不涉及事务。如果需要保留一些API信息，就不需要一堆表。不幸的是，有些人试图让每个场景都适合这个用例，但他们错了!
更进一步说，考虑到人们可能从AWS API中摄取的数据量，存储在集合和文档中的分片和集群数据要比分区和集群SQL数据库简单得多。如果您在操作部门工作，那么文档数据库最终会更容易管理。
因此，虽然我喜欢这里的许多答案，但许多人似乎为自己的阵营进行了辩护，并且/或只是简单地解释了文档数据库可能比基于模式的正交SQL数据库更适合的场景。
经验法则:
