也许你不应该：-）
第二个最明显的答案是，如果您的数据不是关系型的，则应该使用它。这通常表现为没有简单的方法将数据描述为一组列。一个很好的例子是您实际存储纸质文档的数据库，例如，通过扫描办公邮件。数据是扫描的PDF，您有一些始终存在的 meta数据（扫描地点、扫描人、文档类型）和许多可能的元数据字段（有时存在（客户号、供应商号、订单号、存档截止日期、OCRed全文、etc）。通常你事先不知道在未来两年内你会添加哪些元数据字段。像CouchDB这样的东西比关系数据库更适合处理这类数据。
我个人还喜欢这样一个事实，即除了HTTP客户端之外，我不需要任何用于CouchDB的客户端库，现在几乎每种编程语言都包含HTTP客户端。
最不明显的答案是：如果你觉得使用RDBMS没有痛苦，那就继续使用它。如果你总是不得不绕过RDBMS来完成你的工作，那么面向文档的数据库可能值得一看。
有关更详细的列表，请检查this posting of Richard Jones。

从CouchDB说明文件（https://web.archive.org/web/20090122111651/http://couchdb.apache.org/docs/overview.html）：

• “文档数据库服务器，可通过RESTful JSON API访问。”通常，关系数据库不能简单地通过REST服务访问，而是需要复杂得多的SQL API。通常这些API（JDBC、ODBC等）相当复杂。REST则相当简单。
• 专用且无模式，具有平面地址空间。关系数据库具有复杂、固定的模式。您可以定义表、列、索引、序列、视图和其他内容。Couch不需要这种复杂、昂贵、脆弱的高级规划。
• 分布式，具有双向冲突检测和管理的强大的增量复制功能。一些SQL商业产品提供此功能。由于SQL API和固定模式，此功能复杂、困难且昂贵。对于Couch，此功能似乎简单且便宜。
• 可查询和可索引，具有一个面向表的报告引擎，使用Javascript作为查询语言。SQL和关系数据库也是如此。这里没有什么新的。

那么，为什么选择CouchDB？

• REST比JDBC或ODBC简单。
• 没有比模式更简单的模式了。
• 以一种看起来简单和便宜的方式分发。

愚蠢地存储和提供其他服务器的数据。
在过去的几个星期里，我一直在玩一个lifestream应用程序，它会轮询我的feed（delicious、flickr、github、twitter...）并将它们存储在couchdb中。couchdb的美妙之处在于，它让我可以在没有任何开销的情况下保持原始数据的原始结构。我为每个文档添加了一个“class”字段，存储源服务器，并为每个源编写了一个javascript render类。
一般来说，当你的服务器与另一个服务器通信时，无模式存储是最好的，因为你无法控制模式。作为一个好处，couchdb使用服务器和客户端的本地协议- JSON用于表示，HTTP REST用于传输。

快速的应用程序开发。
当我不断地改进我的模式时，我总是因为不得不在MySQL/SQLite中维护模式而感到沮丧。虽然我还没有对CouchDB做太多的工作，但我确实喜欢在RAD过程中改进模式是多么简单。
您可能不想使用非关系数据库的一种情况是，当您有很多多对多关系时;我还不知道如何围绕这类关系创建好的MapReduce函数，特别是在连接关系中需要元数据的情况下。我不确定，但我认为CouchDB Map函数不能在数据库上调用自己的查询，因为这可能会导致无限循环。

当您不需要将数据储存在表格中，且每笔记录的字段大小一致时，请使用以文件为基础的数据库。相反地，您需要将每笔记录储存为具有特定特性的文件。您可以随时将任意数目、任意长度的字段动态新增至文件，而不需要先“修改表格”。以文件为基础的数据库中的字段也可以包含多个数据片段。

详细说明smdelfin：灵活性。你可以在任何结构中存储数据（非结构化的和所有的），每个文档可以完全不同。CouchDB特别有用，因为通过它们的“视图”索引，你可以过滤出特定的文档，当你需要数据库的那些子集时，只查询那个视图。
以JSON格式存储数据的文档数据库最大的优点是：这是JavaScript的本机格式。因此，JavaScript Web应用程序可以非常好地与CouchDB配合使用。我最近开发了一个利用CouchDB的Web应用程序，它的速度非常快，同时还能够处理不断变化的数据结构。

基于文档的数据库比关系数据库有很大的优势，因为它们不需要预先定义模式-在能够输入任何数据之前。
此外，如果您的数据不是相关的，而且无法储存在数据表中，而是一组影像（例如报纸文章），则应该使用文件数据库。
另一个优势是在Web开发中易于使用基于文档的数据库。https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf

一个原因是在JSON（或其他自描述格式）文档上提供快速全文搜索，这些文档不一定具有相同的结构/模式。

这要看情况
是的，这是一个用例的事情。是的，这也是一个开发人员的经验的事情。是的，要输入的数据的性质很重要（高度可预测、正交、合理且易于规范化，或者不太可能以任何有意义的方式进行规范化/组织）。（如果有的话）到另一个问题。是的，您需要如何分析数据很重要。是的，所支持的应用程序的性质是重要的（在应用程序中如何使用数据）。
是的，如果记录/文档的结构（模式）必须快速更改，或者如果字段本身对于每个记录/文档都不是强制性的，则这很重要
是的，如果您有大量的数据要存储，并且希望减少检索时间，这一点很重要。规范化数据（许多独立的不同表中的数据）往往需要以特定的方式放在一起（联接、子查询等），以返回有用的结果。通过只返回几个文档或集合（进行一些筛选），这些相同的结果可能会返回得更快。
哦，是的，为了让新的世界秩序得到认可......是的，那些学习JavaScript或Python作为他们的第一编程语言的人很高兴没有SQL的负担。例如，MongoDB将数据存储为BSON，对于那些只关心获得他们想要的数据的人来说，这实际上就像JSON一样--没有模式，只是存储/获得数据，然后继续下一个任务。
坦率地说，你先学哪一个很重要。如果你先学SQL，那么就有一个地方可以容纳所有的东西。你不介意定义/修改一个模式，因为它可以让你很好地了解你的数据。事实上，有些人喜欢SQL，因为他们喜欢控制的感觉。2他们不介意知道另一种特定领域的语言，因为它给用户带来了强大的功能。由于SQL从70年代就已经存在了，它基本上是老式的商业方式。
使用SQL RDBMS的成本是计划和修改模式（必要时进行分区）、计划表大小和可伸缩性（集群）、学习与数据库接口以及将记录转换为编程语言数据结构（ORM或其他）的时间。
然而，SQL在分析数据和提出复杂问题时非常有效。如果您有不仅仅是简单的存储和检索需求（带有次要分析），那么SQL会让您遥遥领先。
然而，作为应用程序整体的规范化SQL数据库并不一定能满足应用程序的所有数据要求。应用程序（Web或其他）的某些方面可能不是业务持续关注的核心。
如果您想要一个久经考验的符合ACID的事务性（带回滚）记录系统来记录您的财务记录（支付、购买等）---就像您是一家银行--那么无论文档数据库有多好，我都会选择SQL。然而，UI中的一些小部件甚至可能不会触及客户记录/业务事务。为什么要专门为此使用模式呢？
实际上，这是核心UI web开发人员的观点。他们可以证明文档数据库使他们的开发生活简单，但不能使您的业务事务符合ACID。他们获得的经验越多，他们就越会看到文档数据库的便利性就是--便利性。
我敢肯定，就在我键入这些内容时，有人在说XX document DB现在有了符合ACID的事务，但是它有SQL吗？最终，那些希望用document DB来处理所有事务的人会找到一种方法来实现它--这可能意味着（除其他外）集合和文档将有更多的约束，并且它开始变成一种--GASP--形式的模式。
看，使用REST和GraphQL API，您永远不知道从哪里获取数据，也不可能提前预测或计划所有数据的形式。（比如说，与AmazonWebServicesAPI接口），那么文档数据库就很有意义。您不需要规范化那么多数据，您只需要访问、过滤并做一些基本的工作来满足应用程序的需求。将这些数据转储到SQL数据库可能是浪费时间。每次AWS用新数据更新服务时，您可能必须更改代码和架构来适应它。ACKKK！只需将其存储在集合和文档中即可！
上面的AWS API示例不涉及任何事务。如果您需要保留一些API信息，则不需要一堆表。不幸的是，有些人试图使每个场景都适合此用例，他们将是错误的！
更进一步，考虑到从AWS API获取的数据量，对存储在集合和文档中的数据进行分片和聚类要比对SQL数据库进行分区和聚类简单得多。如果您从事运营工作，那么文档数据库最终会更容易管理。

因此，虽然我喜欢这里的很多答案，但许多人似乎为他们的阵营辩护，和/或只稍微解释了文档数据库可能比基于模式的正交SQL数据库更合适的场景。

经验法则：

1.如果它对您的业务运营和持续经营（CRUD、ACID、事务）来说是核心和关键，请选择SQL。
1.如果它只是用于处理应用程序和UI中的大量数据，则文档/ NoSQL数据库。