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

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

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

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

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

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

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

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

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

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

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

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