为什么我应该使用基于文档的数据库而不是关系数据库？
为什么我应该使用基于文档的数据库，如CouchDB，而不是使用关系数据库。 在基于文档的数据库比关系数据库更适合的地方是否有典型的应用程序或领域？
可能你不应该:-)
第二个最明显的答案是你应该使用它，如果你的数据是不相关的。 这通常performance为没有简单的方法将数据描述为一组列。 一个很好的例子就是您实际存储纸质文档的数据库，例如扫描办公室邮件。 数据是扫描的PDF文件，并且您有一些总是存在的元数据（扫描文档types，扫描文档types）和大量可能的元数据字段（客户编号，供应商编号，订单编号，保存文件直到， OCR全文等）。 通常情况下，您事先不知道在未来两年内将添加哪些元数据字段。 像CouchDB这样的数据比关系型数据库更好。
我个人也喜欢这样一个事实，即除了HTTP客户端之外，我不需要任何CouchDB客户端库，现在几乎所有的编程语言都包含这个客户端库。
可能最不明显的答案是：如果使用关系型数据库pipe理系统（RDBMS）感觉不到任何困难，那就留下来 如果你总是需要解决RDBMS来完成你的工作，那么面向文档的数据库可能是值得一看的。
查看Richard Jones的post，查看更详细的列表。
CouchDB（来自他们的网站 ）
-
文档数据库服务器，可通过RESTful JSON API进行访问。 一般来说，关系数据库不是简单地通过REST服务访问，而是需要更复杂的SQL API。 通常这些API（JDBC，ODBC等）相当复杂。 REST很简单。
-
具有平面地址空间的特设和无模式。 关系数据库有复杂的，固定的模式。 你定义表，列，索引，序列，视图和其他东西。 沙发不需要这种复杂，昂贵，脆弱的高级计划。
-
分布式，具有强大的增量复制function，具有双向冲突检测和pipe理function。 一些SQL商业产品提供这个。 由于SQL API和固定模式，这是复杂的，困难的和昂贵的。 对于沙发，它看起来简单而便宜。
-
具有查询function和索引function，以面向表格的报表引擎为特色，该引擎使用Javascript作为查询语言。 SQL和关系数据库也是如此。 这里没有新东西。
所以。 为什么CouchDB？
- REST比JDBC或ODBC更简单。
- 没有Schema比Schema简单。
- 分布的方式看起来简单而便宜。
愚蠢地存储和提供其他服务器数据。
在过去的几个星期里，我一直在玩一个lifestream应用程序，调查我的饲料（美味，flickr，github，twitter …）并将它们存储在couchdb中。 couchdb的美妙之处在于它可以让原始数据保持原有结构，无需开销。 我为每个文档添加了一个“类”字段，存储了源服务器，并为每个源代码写了一个JavaScript呈现类。
一般来说，只要您的服务器与另一台服务器通信，无模式存储是最好的，因为您无法控制模式。 作为奖励，couchdb使用服务器和客户端的本地协议 – JSON表示和HTTP REST传输。
想到快速的应用程序开发。
当我不断发展我的模式时，我经常因为必须在MySQL / SQLite中维护模式而感到沮丧。 尽pipe我还没有用CouchDB做过多的工作，但是我确实喜欢在RAD过程中演变架构的简单性。
你可能不想使用非关系数据库的情况是，当你有很多多对多的关系时， 我还没有弄清楚如何在这些types的关系中创build好的MapReduce函数，特别是如果你需要在join关系中有元数据的话。 我不确定，但我不认为CouchDB Map函数可以调用自己的数据库查询，因为这可能会导致无限循环。
如果不需要将数据存储在每个logging具有统一大小的字段的表中，请使用基于文档的数据库。 相反，您需要将每条logging存储为具有某些特征的文档。 任何长度的任意数量的字段可以随时dynamic地添加到文档，而不需要先修改表格。 基于文档的字段也可以包含多个数据段。
