Document数据库 VS 关系数据库

Document数据库 VS 关系数据库

在今天这个传说中的大数据时代有着各种各样的数据库：开源的，商业的，自研，基于开源系统改进的。一家大公司/大项目不用n个xxxDB，m个数据分析工具都不好意思和人打招呼。

问题是作为一线开发人员（比如写php的，写java的，写node.js的）关心的是怎么搞定需求，早点下班回家，拿到项目奖金才是王道。你这个工具nb，那个db有创新和我的KPI有毛关系？怎么多快好省的完成项目才是王道。

关系数据库大家都比较熟悉了，基本上Mysql/Oracle占据市场的主流；另一方面Document数据库最近也比较火，其中代表是MongoDB和国产的SequoiaDB，FounderXMLDB等等。本文的试图比较一下document数据库和关系数据库的区别，最后会根据笔者的浅薄经验给大家一些使用的建议。

开发角度

这里不谈艰深的理论（我也写不好），从一个码农的使用的角度看：两者其实差不多：
- 关系数据库是写一个SQL，得到一个或多个tuple。
- Document数据库是根据专有的API，得到一个或多个XML/JSON。

有区别吗？似乎没啥大区别。以一个简单的SNS用户信息JSON API来说：
- 关系数据库的用法是：根据用户id从用户基本信息表，用户勋章表，用户登陆表表中获取数据；然后用getInt，getString等获取数据，最后再用result = createJson(); result.put('name', strName)之类的拼成一个JSON返回。
- Document数据库，通过一个API，获取一个JSON，然后返回。

显然Document类要方便的多。
- 什么？你有框架/IDE生成代码？嗯，你试过增加一项或者减少一项吗？P.S. 靠框架/IDE混不利于涨工资。
- 什么？你们公司按行数给工资？嗯，我能建议你换家公司吗？

稍微提高一点层次，到数据库设计的角度，两者就有区别了。关系数据库是需要建表的，create table ...，还记得数据库考试的时候有所谓的数据库三大范式吗？而document数据库是scheme-less的，也就是没有模式的，不用在建表的时候就确定详细的表结构。

这一轮Document数据库胜，能少敲不少机械的代码。

补充一下，目前的document数据库基本上不支持Join操作。如果需要join操作请绕路。

性能角度

放google可以找到好多的测试报告，这里就不再贴具体的性能对比了。实际上，根据笔者的经验，在适合使用Document数据