关系型数据库为什么能活这么久？

我就是你们常用的关系型数据库， IBM的研究员E.F.Codd 于1970年把我的理论带到这个世界上，我已经快50岁了。

我的家族成员居住在世界各地性能强悍的服务器中， 保存着你们人类的大量珍贵的数据，从你的银行余额，到你的购物清单，几乎每一笔网上交易都有我们负责保存。

我是如此重要，几乎每一位软件从业者都需要认真学习，很多时候我都是存储大量数据的首选，你要做的，就是选择一个我的家族成员而已，比如：Oracle, MySQL, Db2，SQL Server这些家伙。

对了，还有一个小巧玲珑的SQLite，做手机端开发的离不开它。

在日新月异的IT界， 一门技术居然能存活这么久，实在是不可思议。

也许会有人想到这个问题： 你为什么能活这么久？

简单地拍脑袋想一想，也许是我能够大规模地保存和检索数据？  但是直接使用文件系统也可以啊？

为什么要数据库？ 还“关系”？

不，我能活这么久，是有一些独门秘籍的。

1.我有着坚实的数学基础

这可真不是我吹牛，我的身上处处显示着高贵的数学身影：

域，关系，笛卡尔积

关系代数：选择，投影，连接

......

对了，你知道啥叫“关系”吗？ 面试官如果问你的话你该如何回答？

其实所谓关系，在数学上的定义就是笛卡尔积的一个子集。

例如有两个集合：

s1 ={a,b} 

s2 = {1,2} 

那s1和s2的笛卡尔积就是 ：

s1 × s2 = {(a,1),(a,2),(b,1),(b,2)} 

那么S 的任意一个子集都是关系：

{(a,1),(a,2)} 是一个“关系”

{(a,2), (b,1),(b,2)} 是另外一个“关系”

{(b,2)} 也是关系

......

如果你把s1和s2竖起来看，把s1看做列x能取值的集合， s2看做列y 能取值的集合， 那(x, y)它不就是一张表吗？

我还有个很漂亮的性质：

关系(表)经过运算以后，如select，join，where，交、并、差，结果还是一个关系（表）!

你看我的数学基础是不是很牢靠？

2.我很直观

至少表面上看起来是这样的，如果你想给一个非计算机专业的人讲解数据库，可以和Excel类比下， 看看他能不能听懂： 瞧， 这不就是个表格吗，有行有列的。

3.使用简单

这里不得不说说SQL这个优秀的抽象层，它完全屏蔽了底层的实现细节，你完全不用考虑底层的文件是怎么存放的，只要发出SQL : SELECT ...... FROM ...... WHERE ...... 就好。

相比于早期复杂的层次状，网状数据库， SQL实在是太简单了。

不仅仅是开发人员，你们的业务人员稍加培训就可以写SQL,  我清晰地记得有个业务分析师经常去数据库查数据，然后告诉程序员说数据不对，有Bug， 让程序员非常头疼。

4.对数据完整性的支持很好

我的每个字段都有确定的类型，还可以检查数据的长度，取值范围。

我的主键和外键，共同保证了数据的精确性和一致性， 防止数据的缺失。

5.我支持事务！

这可能是我能成功的一大关键了， ACID对于核心系统的数据（如银行账号）无比重要，不难想象一个转账操作没有完成会带来什么样的影响。

6.范式

想要使用我们关系型数据库，必须得遵守一定的规则，这些规则就是“范式”。

第一范式是基本要求，即每个列都是不分割的数据项， 如果连这个都满足不了，还是洗洗睡吧。

第二范式要求实体属性要完全依赖主键，不能依赖部分主键。

第三范式就是一个表中不能包含其它表中已包含的非主关键字信息。不严谨地说就是这个表只包含其他表的ID。

一般来说，你们都会遵循第一和第二范式， 但是为了性能，为了避免过多的join, 有时候会违反第三范式，冗余一些字段的信息， 这我都可以理解。

7.大家用我做“数据的集成”

这是大牛Martin Fowler 提出的观点：

企业级应用程序居于一个丰富的生态系统中，它需要与其他应用程序协同工作，而那些程序是由不同的团队合作开发出来的。

不同的应用程序经常要使用同一份数据， 而且某个应用程序更新完数据以后，必须让其他应用程序知道这份数据已经改变了。

采用”共享数据库集成“ ，多个应用程序都将数据保存在一个数据库中，所有的应用很容易就能使用彼此的数据了。

8.遗留数据