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