为什么我应该使用基于文档的数据库，例如CouchDB而不是使用关系数据库。是否有任何典型的应用程序或领域比基于关系数据库更适合基于文档的数据库？
也许你不应该：-）
第二个最明显的答案是，如果您的数据不是关系数据，则应使用它。这通常表现为没有简单的方法将您的数据描述为一组列。一个很好的例子是一个数据库，您实际上可以在其中存储纸质文档，例如通过扫描办公室邮件。数据是已扫描的PDF，并且您有一些始终存在的元数据（在文档中扫描，按文档类型扫描）以及可能在某个时间存在的许多可能的元数据字段（客户编号，供应商编号，订单编号，保留在文件上， OCRed全文，等等）。通常，您不预先知道在未来两年内将添加哪些元数据字段。像CouchDB这样的事情对于这种数据比关系数据库要好得多。
[我个人也很喜欢这样一个事实，除了HTTP客户端，CouchDB我不需要任何客户端库，如今，几乎所有编程语言都包含HTTP客户端。
可能是最不明显的答案：如果使用RDBMS时没有痛苦，请继续使用它。如果您总是需要解决RDBMS才能完成工作，那么面向文档的数据库可能值得一看。
有关更详细的列表，请检查this posting of Richard Jones。
CouchDB（来自他们的website）
文档数据库服务器，可通过RESTful JSON API访问。通常，关系数据库不是简单地通过REST服务访问的，而是需要复杂得多的SQL API。通常，这些API（JDBC，ODBC等）非常复杂。 REST非常简单。
即席且无模式，具有平坦的地址空间。关系数据库具有复杂的固定架构。您可以定义表，列，索引，序列，视图和其他内容。 Couch不需要这种复杂，昂贵，脆弱的高级计划。
Distributed，具有强大的增量复制功能，具有双向冲突检测和管理功能。一些SQL商业产品提供了此功能。由于SQL API和固定的架构，这是复杂，困难且昂贵的。对于Couch，它看起来简单又便宜。
可查询和可索引，具有面向表格的报表引擎，该引擎使用Javascript作为查询语言。 SQL和关系数据库也是如此。这里没有新内容。
所以为什么选择CouchDB？
用于愚蠢地存储和服务其他服务器数据。
[在过去的几周中，我一直在使用一个生命周期应用程序，该应用程序轮询我的提要（美味，flickr，github，twitter ...）并将其存储在沙发数据库中。 couchdb的优点在于，它使我可以将原始数据保持在其原始结构中，而没有任何开销。我在每个文档中添加了一个“类”字段，存储了源服务器，并为每个源编写了一个javascript渲染类。
概述，每当您的服务器与另一台服务器通信时，最好使用无模式存储，因为您无法控制该模式。另外，couchdb使用服务器和客户端的本机协议-JSON用于表示，HTTP REST用于传输。
想到快速的应用程序开发。
[当我不断发展自己的架构时，由于不得不在MySQL / SQLite中维护该架构，我不断感到沮丧。尽管我对CouchDB的工作还不多，但我喜欢在RAD流程中发展模式如此简单。
您可能不希望使用非关系数据库的情况是，您具有许多多对多关系；我还没弄清楚如何围绕这些类型的关系创建良好的MapReduce函数，尤其是如果您需要在联接关系中包含元数据时。我不确定，但是我不认为CouchDB Map函数可以在数据库上调用它们自己的查询，因为这可能会导致无限循环。
当您不需要将数据存储在每个记录的字段大小统一的表中时，请使用基于文档的数据库。相反，您需要将每个记录存储为具有某些特征的文档。可以随时将任意长度的任意数量的字段动态添加到文档中，而无需先“修改表”。基于文档的字段也可以包含多个数据。
详细阐述smdelfin：灵活性。您可以将数据存储为任何结构（非结构化且全部结构化），并且每个文档都可以完全不同。 CouchDB特别有用，因为有了它们的“视图”索引，您就可以过滤出特定的文档，并在需要数据库的那些子集时仅查询该视图。
我以JSON格式存储数据的文档数据库的最大赢家：这是JavaScript的本机格式。因此，JavaScript Web应用程序与CouchDB配合得非常好。我最近制作了一个网络应用程序，该应用程序利用CouchDB并迅速发展，同时还能够处理不断变化的数据结构。