大家都在用的“关系数据库”，竟是各种IT事故的根源

如果说在你看来这似乎是很愚蠢的做事方式的话，你的感觉完全正确。

这大概是有史以来做出的最愚蠢的，被使用得最广泛、代价最高昂的技术决定了。

这种软件就相当于核电站将控制室跟参观室设在了一起。

把两个东西拆开，也就是一个是命令，一个是来自表格的数据，然后再合并到一起，接着反复进行一场不要被愚弄把数据当成命令的实际部分的技术战争，这种做法根本毫无意义。

为什么一开始就要把它们揉到一起呢？

这就是一个非常糟糕的架构，这个架构要为全球各个组织数十亿美元的损失负责。

但是关系式数据库的故事比这还糟。

不要重复自己

假设你有一份实现软件的工作时间记录表（timesheet）。这份记录表有一个员工号。现在你要展示这份工作时间记录表，同时你想将员工姓名找出来。但姓名是在员工表上的，所以你得创建一条像这样的SQL语句：

SELECT EMPLOYEE WHERE EMPLOYEE.NUMBER EQUALS TIMESHEET.EMPLOYEE_NUMBER输入

这条语句会查询员工表将其与timesheet表进行匹配。你在这里做的其实是定义员工与timesheet的关系。你可以说他们是通过timesheet上的员工号连接在一起的。

记住那份timesheet表格已经描述给软件了。你说timesheet上的字段是员工号，所以基本上此时软件已经知道了这一关系了。但是现在你却要很麻烦地构建一条SQL语句然后发给数据库去执行，然后在返回一组表的行记录再从中选出你需要的信息。这完全是毫无必要！因为这份timesheet上与员工有关的信息已经跟软件沟通过了。采用关系式数据库导致这一信息被无视并且还得用一种完全不同的语言去重新定义这种关系。

计算机科学有一条原则叫做DRY（Don’t Repeat Yourself），意思是不要重复自己。其主要信条是每个不同的代码片段或数据仅在一个位置上出现。代码你应该编写一次然后在计算需要的时候进行调用。然而，这一原则也延伸到各个消除冗余性的地方。这是一条减少无序/复杂性的原则。相同的计算采用相同的代码消除了两个不同的实现走乱步伐的可能性。

用SQL表达已经在不同的表格上被表示过的数据之间的“关系”完全就是对DRY原则的违背。在软件里面信息是很宝贵的。信息被捕捉到之后就应该物尽其用，永远都不应该重新输入这一信息。你永远都不应该输入某个可以通过之前输入过的地方获取的东西。这么做就会制造出一条信息两个版本搞乱的可能性。

自从关系式数据库被提出以来，我就一直对为什么这种似乎非常怪异的架构还能存在感到困惑。

这就好像让你的档案室讲外语然后所有的指令都要用那门语言编写一样。

但情况其实还要糟糕。当你把那份timesheet保存进关系式数据库时，你必须把它分开，头信息放在一个表，所有分配工时给项目的明细记录又是一行行记录组成的另一张表。你必须把那张表拆开然后构建SQL来操作和存储它们。哦是的，如果你想按照同样的次序还原那张工时记录表的话，你还得给每一条明细记录行分配一个序号。当你想要要回那张表时，你得编写SQL指令将表格联合起来然后你还得从返回结果中选择所有的timesheet信息再拼凑成一份表格。