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

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

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

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

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

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

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

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

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

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

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

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

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

域,关系,笛卡尔积

关系代数:选择,投影,连接

......

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

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

例如有两个集合:

  1. s1 ={a,b} 
  2. s2 = {1,2} 

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

  1. 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.遗留数据

几十年来,我这里积累了大量的应用数据,虽然说城头变幻大王旗,访问关系数据库的应用程序变了好几茬,编程语言也换了好几波,但是关系数据库中的数据岿然不动,他们的寿命远远超过应用程序的寿命, 数据变成了一个企业宝贵的财富。

但是世界上没有***的东西, 我虽然有众多优点, 但是也有不少缺点。

在互联网时代, 在高并发,大流量的映衬下,这些缺点显得格外刺眼:

对分布式系统支持不好, 难于组成集群,水平扩展比较难。

复杂的类型(XML、JSON等)不好表达。

应对互联网的海量请求力不从心。

......

为了应对这些问题,你们人类可以说是想了很多办法,比如什么NoSQL数据库,什么分库分表,在比如你们发展了BASE理论,不追求ACID中的强一致性,只要达到“基本可用”,最终一致性就可以了。

但是我不得不说,对于核心的数据,交由我来保管才是正道。

我已经快50了,不知道能不能再活50年,但是再活20年我觉得是没问题的,所以,我建议你还是好好学习一下吧。

【本文为51CTO专栏作者“刘欣”的原创稿件,转载请通过作者微信公众号coderising获取授权】

戳这里,看该作者更多好文

责任编辑:武晓燕 来源: 51CTO专栏
相关推荐

2021-05-28 06:16:28

蓝牙Wi-FiNFC

2015-04-24 13:59:41

2020-10-27 09:18:16

ClickHouse数据库架构

2023-09-05 10:25:35

数据库性能

2022-02-08 13:39:35

LinuxUNIX系统

2018-07-18 09:16:39

关系型非关系型数据库

2021-05-27 21:18:56

谷歌Fuchsia OS操作系统

2021-04-28 11:35:06

Java框架日志

2019-08-26 10:36:38

Python操作系统高考

2018-01-31 10:24:45

热插拔原理服务器

2021-09-06 10:24:12

鸿蒙HarmonyOS应用

2022-08-21 14:00:11

消息中间件MQ

2013-01-24 09:44:44

数据库

2011-03-15 14:54:08

NoSQL

2010-12-10 10:17:21

关系型数据库

2022-06-13 08:30:01

数据库管理系统

2017-03-17 14:44:04

关系型数据库原理

2020-02-15 15:33:55

Python如何运作

2020-12-01 10:18:16

RabbitMQ

2020-03-30 09:22:03

AI语音技术机器视觉
点赞
收藏

51CTO技术栈公众号