提问



为什么我应该使用像CouchDB这样的基于文档的数据库而不是使用关系数据库。
是否存在基于文档的数据库比关系数据库更适合的典型应用程序或域?

最佳参考


可能你不应该:-)


第二个最明显的答案是,如果您的数据不是关系型的,您应该使用它。这通常表现为没有简单的方法将您的数据描述为一组列。一个很好的例子是您实际存储纸质文档的数据库,例如,通过扫描办公室邮件。数据是扫描的PDF,您有一些元数据始终存在(扫描,扫描,文档类型)和许多可能的元数据字段,有时存在(客户编号,供应商编号,订单编号) ,保持存档直到,OCRed全文,等等。通常你不知道你将在未来两年内添加哪些元数据字段。
像CouchDB这样的数据比关系数据库更适合这种数据。


我个人也喜欢这样一个事实:除了HTTP客户端之外,我不需要CouchDB的任何客户端库,现在几乎所有的编程语言都包含它。


可能最不明显的答案是:如果您觉得使用RDBMS没有痛苦,请坚持下去。如果您总是需要解决您的RDBMS来完成工作,那么面向文档的数据库可能值得一看。


有关更精细的列表,请查看Richard Jones的帖子。[1]

其它参考1


CouchDB(来自他们的网站)[2]



  • 可通过RESTful JSON API访问的文档数据库服务器。通常,关系数据库不是通过REST服务简单访问,而是需要更复杂的SQL API。通常这些API(JDBC,ODBC等)非常复杂。 REST非常简单。

  • Ad-hoc和无架构,具有扁平地址空间。关系数据库具有复杂的固定模式。您可以定义表,列,索引,序列,视图和其他内容。 Couch并不需要这种复杂,昂贵,脆弱的高级计划。

  • 分布式,具有强大的增量复制功能,具有双向冲突检测和管理功能。一些SQL商业产品提供此功能。由于SQL API和固定模式,这是复杂,困难和昂贵的。对于Couch来说,它看起来简单而且便宜。

  • 可查询和索引,具有使用Javascript作为查询语言的面向表的报告引擎。 SQL和关系数据库也是如此。这里没什么新鲜的。



所以。为何选择CouchDB?



  • REST比JDBC或ODBC更简单。

  • 没有Schema比Schema简单。

  • 以简单而廉价的方式分发。


其它参考2


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


在过去的几个星期里,我一直在玩一个生命流应用程序,它可以轮询我的feed(美味,flickr,github,twitter ......)并将它们存储在couchdb中.sandydb的美妙之处在于它可以让我保留原始数据在原始结构中没有开销。我在每个文档中添加了一个类字段,存储了源服务器,并为每个源编写了一个javascript渲染类。


概括,只要您的服务器与另一台服务器通信,无架构的存储最好,因为您无法控制架构。作为奖励,couchdb使用服务器和客户端的本机协议 - 用于表示的JSON和用于传输的HTTP REST。

其它参考3


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


当我不断发展我的架构时,我不得不在MySQL/SQLite中维护架构而感到沮丧。虽然我还没有对CouchDB做太多,但我确实喜欢在RAD过程中发展模式是多么简单。


您可能不想使用非关系数据库的情况是您有很多多对多关系;我还没有理解如何围绕这些关系创建好的MapReduce函数,特别是如果你需要在加入关系中有元数据。我不确定,但我不认为CouchDB Map函数可以调用他们自己对数据库的查询,因为这可能会导致无限循环。

其它参考4


如果不需要在每个记录中具有统一大小字段的表中存储数据,请使用基于文档的数据库。相反,您需要将每条记录存储为具有某些特征的文档。任何长度的任意数量的字段都可以随时动态添加到文档中,而无需先修改表格。基于文档的字段也可以包含多个数据。