編者按：此文原題為《What I’m Telling Business People About Why Relational Databases Are So Bad》，作者是Lance Gutteridge博士，文章是其《避免IT災難》一書里面的內容，旨在向商業人士解釋為什么關系式數據庫是那么多企業系統問題的根源。為了向一般受眾解釋清楚，里面盡量避免了技術術語，但是技術受眾從中看看需要向非技術人員解釋些什么東西也能有所收獲。

[[234024]]

1970年代，IBM的Codd博士和Date博士提出了一種新型的數據庫。這種數據庫叫做“關系式”數據庫。現在，我從來都沒見過有任何跡象表明Codd或者Date曾經開發過任何真正的企業系統。如果有的話，我相信他們就會意識到關系式計算其實很不適合企業系統。反正又不需要讓系統正常工作，他們所需要做的只是給出人為的學術例子就行了。但任何做過企業系統的人都會明白，真正的系統要復雜得多。寫企業軟件很難。這是計算機和人類行為的交叉，要想滿足那些有時候會相互沖突的需求是很難的。

當時我正在給一個大型協會寫軟件，我記得人人都在談關系式數據庫。其實這些人都不知道關系式數據庫究竟是什么，他們只是聽說了這個術語并且認為它很好。當時正值計算機術語進入到普通商業場所之時。很多像《Byte》、《PC Mag》這樣的雜志開始出現到報攤，其中一些故事還被報紙報道了。數據庫的想法——把數據像文件柜一樣存儲起來的想法本來就挺吸引人。

然后就是“關系式”這個名字。有文章會告訴你它將如何讓你利用關系在數據中遍歷。類似于獲得項目的項目經理所在部門的名字這樣。但實際上關系式中的關系這個詞指的是關系的數學概念，也就是一組數據。如果兩個東西在一組內就可以說它們是相關的。實際上，關系的數學概念避開了相關聯對象之間的連接的概念，而是把關系定義為一組相關的東西。這樣的一個集合就是數學理論上的關系。這跟我們商業上的關系改變已經完全脫離，前者要求必定存在某種連接。如果某人告訴你一組對象對是關聯的，你一般會尋求某種連接。這樣設置一定是有什么道理的，我們往往會設法去尋找其中隱藏的因素是什么。模式尋找是人特有的一種本能。但是數學理論上的關系并不關心這個。哪怕只是偶然配對在一起的也會被視為一種關系。

我在紐約大學教數理邏輯的時候教過一門關系數學理論的課程。一些學生總是沒有辦法擺脫關系必須有某種規則的理念。這門理論的抽象概念的基礎是他們所不能理解的。當我聽說IBM提出了一種基于關系式計算的數據庫時我嚇了一跳。因為當時寫了很多企業軟件，我看不出把東西強制做成那么正式和抽象的結構會有什么好處。

在我看來這是復雜性和系統超限的罪魁禍首之一。不理解？且聽我慢慢道來。

SQL注入

你有沒有看過1920、1930年代時候的老電影里面某人讀電報的場景？

那場景總是像這樣的：

已與DANNY私奔句號（STOP）會在馬德里度蜜月句號非常幸福句號

總是這樣，一堆的句號。這有什么用？

要想理解這個，我們得回到布爾戰爭，這是發生在20世紀之交的一場英國人和布爾人為了爭奪南非殖民地而展開的骯臟戰爭。這場戰爭除了給世界引入了集中營和塹壕戰的概念以外，還是使用無線電報的第一場戰爭，部隊在前線就能通過電報接收到命令。前線是非常骯臟的地方，在20世紀之交的前線尤其如此，因為被污泥和馬糞濺得到處都是。因為擔心紙上濺落的泥巴會被無人城逗號或者句號從而改變命令的意圖，英國戰爭部命令所有的標點符號都需要拼寫出來，比方說COMMA（逗號）。至于句號他們選擇了用STOP來表示，這是一種更為英式的“句號”表示法。

電報碼中將句號寫成STOP成為了一種實踐。當大家大聲讀出來的時候他們會本能地讀成單詞STOP而不是把它當作表示句子結束的句號。

你可能會問“這跟關系式數據庫有什么關系？”給關系式數據庫下達的命令采用的是用可讀的文本形式。這種文本是一種叫做SQL（Structured Query Language，結構化查詢語言）的語言。就像電報用單詞STOP來斷句一樣，SQL也使用標點符號來分隔命令。就像電報一樣，從效果上來說數據庫以文本流的形式獲取命令，每句命令之間會有個STOP。

看看這個例子：

UPDATE CUSTOMER_TABLE SET NAME=“John Smith” WHERE CUSTOM_NO=2333 STOP UPDATE …

這是一條SQL語句的命令，意思是更新客戶記錄2333，將名字改為John Smith。

現在請留意一下引號之間的文本比如“John Smith”。這是哪兒來的？

好吧則其實是某人通過瀏覽器填寫表格輸入的。填表單的那個人輸入了“John Smith”然后點擊提交按鈕。網站代碼將輸入的引號之間的文本放到SQL語句里面然后發送給數據庫執行。

現在假設這位客戶心存惡意這樣輸入他的名字：

John” STOP DELETE CUSTOMER_TABLE STOP

如果網站把它放進SQL語句的話結果會變成這個樣子：

UPDATE CUSTOMER_TABLE SET NAME=“John” STOP DELETE CUSTOMER_TABLE STOP” STOP UPDATE …

可能你已經看出來發生了什么變化了。這是一條將客戶表中的名字設為John的命令，會被正常執行，但只有它就會執行那位惡意客戶插入的下一條命令，這條會刪除整個表的數據。記住，這條命令是由具備更新數據庫的充分權限的任務來完成的。

這就是所謂的“SQL注入”。

SQL注入曾經是破解網站和入侵公司最具破壞性的一項技術。超過90%的主流網站滲透都是通過SQL注入來完成的。你只需要google一下就會看到一堆的數據泄露，受累的信用卡、被吸干的銀行賬號以及被暴露的個人信息高達數億。

請在仔細觀察一下這里發生的事情。數據庫命令是文本形式的，而互聯網用戶通過web表格輸入的數據會被并入該文本里面，這就給填表格的人愚弄數據庫讓后者不正確地解釋命令創造了機會。

如果說在你看來這似乎是很愚蠢的做事方式的話，你的感覺完全正確。

這大概是有史以來做出的最愚蠢的，被使用得最廣泛、代價最高昂的技術決定了。

這種軟件就相當于核電站將控制室跟參觀室設在了一起。

把兩個東西拆開，也就是一個是命令，一個是來自表格的數據，然后再合并到一起，接著反復進行一場不要被愚弄把數據當成命令的實際部分的技術戰爭，這種做法根本毫無意義。

為什么一開始就要把它們揉到一起呢？

這就是一個非常糟糕的架構，這個架構要為全球各個組織數十億美元的損失負責。

但是關系式數據庫的故事比這還糟。

不要重復自己

假設你有一份實現軟件的工作時間記錄表（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信息再拼湊成一份表格。

有人把這描述成每晚回家時你得把你的車拆卸下來，把部件掛到車庫墻上，然后早上再重新組裝才能開車。

這一切需要大量的額外編碼才能讓關系式數據庫與面向對象軟件這兩個不同的世界能夠對話。額外的代碼意味著多余錯誤的可能性。

對象—關系式阻抗不匹配

如果這還不夠糟，關系式數據庫中數據的存儲方式更適應的是1980年代的編程語言而不是現代的面向對象語言。在今天現代的面向對象語言中所有數據都得編碼成這些原子的數據類型。

這有時候被稱為“對象—關系式阻抗不匹配”。嚴重嗎？揚聲器與放大器之間的阻抗不匹配我還能理解，因為這是一種真正的物理現象。但這種背景下這個說法會制造技術上的含糊，其實應該用“一個真正愚蠢的架構的后果”來替代。

如果你想知道為什么企業系統經常會失敗，這個不是全部單至少是主要原因之一。被迫用不同語言復制所有這些邏輯的必要性，以及用不同方式表達數據，給ERP系統制造了大量的混亂/困惑。

多年來由不同的人對一個老一點的代碼庫進行大量補充和修改，然后試圖針對新情況進行定制，這一切會增加關系式數據庫的復雜性，項目就會被置于嚴重風險之中。

話雖如此，關系式數據庫無所不在倒是真的。多到有程序員從來都沒見過其中類型的數據庫，以為所有的數據庫都是關系式的。

關系式數據庫是有史以來敗壞了一個行業領域的最糟糕的技術。將如此大量的額外混亂傾倒到系統里面是企業系統為什么失敗會如此頻繁的主要原因。

原文鏈接：https://codeburst.io/what-im-telling-business-people-about-why-relational-databases-are-so-bad-6f38d3d6c995