为什么我应该使用基于文档的数据库而不是关系数据库？

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

1> max..：

---

可能你不应该:-)

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

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

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

有关更精细的列表,请查看Richard Jones的这篇文章.

---

@ int3如果您无法将数据描述为一组列,那么您应该如何对所述数据编写智能查询？

2> S.Lott..：

---

CouchDB(来自他们的网站)

可通过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更简单.

以简单且廉价的方式分发.

---

虽然我是NoSQL数据库的忠实粉丝,但第一个主张(REST比JDBC简单)非常可疑.

---

@ S.Lott答案不应该更"通用"而不是仅仅针对CouchDb吗？

---

REST协议对我来说似乎很简单,因为它只是HTTP:无状态,很少的方法等等.也许JDBC(引擎盖下)很简单; 它似乎并不简单,仅仅基于有状态.

3> daonb..：

---

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

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

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

---

因为couchdb还允许您使用map/reduce创建有趣的视图.例如,我可以基于数据源创建视图,或者我可以计算每个源的总计.

---

这是一个很好的观点...如果您正在使用数据并且无法控制入站数据模式 - 请使用文档存储.

4> pixelcort..：

---

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

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

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

5> 小智..：

---

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