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

编者按：此文原题为《What I’m Telling Business People About Why Relational Databases Are So Bad》，作者是Lance Gutteridge博士，文章是其《避免IT灾难》一书里面的内容，旨在向商业人士解释为什么关系式数据库是那么多企业系统问题的根源。为了向一般受众解释清楚，里面尽量避免了技术术语，但是技术受众从中看看需要向非技术人员解释些什么东西也能有所收获。

1970年代，IBM的Codd博士和Date博士提出了一种新型的数据库。这种数据库叫做“关系式”数据库。现在，我从来都没见过有任何迹象表明Codd或者Date曾经开发过任何真正的企业系统。如果有的话，我相信他们就会意识到关系式计算其实很不适合企业系统。反正又不需要让系统正常工作，他们所需要做的只是给出人为的学术例子就行了。但任何做过企业系统的人都会明白，真正的系统要复杂得多。写企业软件很难。这是计算机和人类行为的交叉，要想满足那些有时候会相互冲突的需求是很难的。

当时我正在给一个大型协会写软件，我记得人人都在谈关系式数据库。其实这些人都不知道关系式数据库究竟是什么，他们只是听说了这个术语并且认为它很好。当时正值计算机术语进入到普通商业场所之时。很多像《Byte》、《PC Mag》这样的杂志开始出现到报摊，其中一些故事还被报纸报道了。数据库的想法??把数据像文件柜一样存储起来的想法本来就挺吸引人。

然后就是“关系式”这个名字。有文章会告诉你它将如何让你利用关系在数据中遍历。类似于获得项目的项目经理所在部门的名字这样。但实际上关系式中的关系这个词指的是关系的数学概念，也就是一组数据。如果两个东西在一组内就可以说它们是相关的。实际上，关系的数学概念避开了相关联对象之间的连接的概念，而是把关系定义为一组相关的东西。这样的一个集合就是数学理论上的关系。这跟我们商业上的关系改变已经完全脱离，前者要求必定存在某种连接。如果某人告诉你一组对象对是关联的，你一般会寻求某种连接。这样设置一定是有什么道理的，我们往往会设法去寻找其中隐藏的因素是什么。模式寻找是人特有的一种本能。但是数学理论上的关系并不关心这个。哪怕只是偶然配对在一起的也会被视为一种关系。

我在纽约大学教数理逻辑的时候教过一门关系数学理论的课程。一些学生总是没有办法摆脱关系必须有某种规则的理念。这门理论的抽象概念的基础是他们所不能理解的。当我听说IBM提出了一种基于关系式计算的数据库时我吓了一跳。因为当时写了很多企业软件，我看不出把东西强制做成那么正式和抽象的结构会有什么好处。

在我看来这是复杂性和系统超限的罪魁祸首之一。不理解？且听我慢慢道来。

SQL注入

你有没有看过1920、1930年代时候的老电影里面某人读电报的场景？

那场景总是像这样的：

已与DANNY私奔句号（STOP）会在马德里度蜜月句号非常幸福句号

总是这样，一堆的句号。