为什么要有关系数据库——一篇旧帖分享

今天在某群中看到“文件保存到数据库与用FileStream直接写到磁盘中，哪个效率更高？”的讨论，并贴出了一个CU上类似主题的帖子链接。此帖2005年4月发表，标题是“读写文件不是效率很低的嘛，那么数据库为何效率高呢？”，讨论十分热烈。

这两个问题都提到数据库的效率，前者是因MS-SQL2008的一项新功能而起，后者问题本身就引起了争论，后面的跟帖集中在“数据直接存储在文件系统和存储数据库中哪一个效率高”之辩。跟帖中有一位参与讨论的仁兄写了篇生动的小文章来阐述他对数据库的理解，我觉得是亮点，转过来分享一下。另一位仁兄列出了几种常见的数据组织形式简单对比，具备一些参考价值，同样也转一下。还有一位仁兄（2eye@CU）总结了大家的看法，认为数据库的高效，“是通过对数据的更有效组织使得我们可以更高效的查询到我需要的那部分数据”，精辟的理解。

 1、四种常见数据组织形式对比

（作者mirnshi@CU，个别文字调整）

方式	I/O	数据量	数据组织	使用	API	数据管理
普通文件	高	小	简单	难	自己设计	无法直接查看/借助通用编辑器
文件DB	高	中	简单	中	专有的API	借助工具查询
LDAP	中	大	中	中	统一的API	可以直观察看
SQL DB	低	超大	复杂	易	专有丰富的API及SQL语言	借助标准SQL语言

文件DB指以key/value的形式来组织数据，可实现相对方便快捷的访问，如Berkeley DB。

SQL DB特指关系型数据库。

 2、为什么要有关系数据库

（作者bennie@CU，校正个别文字，标题为后加）

在遥远的古希腊，有一天柏拉图正在学院里看书，停下来休息的时候，正看到他的学生亚里士多德从外面走来。
亚：老师，马其顿王刚才有个任务交给我们，让我们处理一下学院内所有学生的资料。老师，我们怎么做呢？我听说遥远的东方那边有一个新东西，叫关系数据库，据说还不错，我们是不是拿来用一下。
柏(撇了撇嘴角)：切，我们伟大的希腊，伟大的柏拉图学院怎么会用他们的东西，不就是存一些学生的数据么，我们自己来解决。你过来，我们设计一下。
亚走近前来，柏从书架上拿出一卷羊皮纸，开始画图，并给亚解释：嗯，你看我们在羊皮纸上顺序的存所有的学生，然后给每个学生编一个连续的号码，然后直接根据学号跳到对应的页数，不就可以了么。这样的效率可是O(1)的。听说那个数据库光准备阶段就要10张羊皮纸，还得把一些张做成服务型，真是没必要。慢死了。
亚：可是老师，如果某些学生被征去兵役，或者病死，那不是中间的某些号码就要缺失了么？
柏：嗯，这是个问题，这样吧，我们依旧要顺序存储，但是是排序的，找的时候像查字典那样，对半翻，这样效率也可以达到O(lgN)。怎么样？
亚：这样很好，不过我们可能会在前面插入学生的，因为听说那些长老院的子弟很喜欢带8的数字，他们一定会插到前面的。
柏：那我们可以做成链接的，有一个索引的表，就像两千多年后的B+树那个样子，这样就解决了插入的效率问题。
亚：老师，可是。。
柏：你怎么这么多问题，真是的。
亚：老师，我是说，你连2000年后的事情都知道，真是希腊最伟大的哲学家！
柏：呵呵。。
亚：对了，老师，但是王一般都是按着名字来找人的，那我们怎么办？
柏：嗯，这个难不住我，我们另建一个索引表，把名字进行HASH查找，这样的效率是近似于O(1)的。
亚：老师真厉害，不过王还需要根据别的多个条件，比如大于18岁，家里父母健在的要去服兵役的。
柏：这个王也够麻烦的，那我们创造一个结构化查询语言好了，就叫他SQL好了，他的语法是这样这样的。。。。，对了，还得弄个接口去解释他。还有，后面那些东西得弄个东西去管理。
不知不觉中，柏所画下的图已经铺满了整个大厅。
亚：老师，可是我听说东方那个关系数据库就是这个样子的，既然这样，我就去东方学习好了，因为听说他们已经作了很多年了，应该有很多人用！
说完，亚转身走出了学院，对着遥远的东方，亚喃喃自语：吾爱吾师，吾更爱真理！