關(guān)系型數(shù)據(jù)庫為什么能活這么久？
我就是你們常用的關(guān)系型數(shù)據(jù)庫， IBM的研究員E.F.Codd 于1970年把我的理論帶到這個(gè)世界上，我已經(jīng)快50歲了。
我的家族成員居住在世界各地性能強(qiáng)悍的服務(wù)器中， 保存著你們?nèi)祟惖拇罅空滟F的數(shù)據(jù)，從你的銀行余額，到你的購物清單，幾乎每一筆網(wǎng)上交易都有我們負(fù)責(zé)保存。
我是如此重要，幾乎每一位軟件從業(yè)者都需要認(rèn)真學(xué)習(xí)，很多時(shí)候我都是存儲大量數(shù)據(jù)的***，你要做的，就是選擇一個(gè)我的家族成員而已，比如：Oracle, MySQL, Db2，SQL Server這些家伙。
對了，還有一個(gè)小巧玲瓏的SQLite，做手機(jī)端開發(fā)的離不開它。
在日新月異的IT界， 一門技術(shù)居然能存活這么久，實(shí)在是不可思議。
也許會有人想到這個(gè)問題： 你為什么能活這么久？
簡單地拍腦袋想一想，也許是我能夠大規(guī)模地保存和檢索數(shù)據(jù)？ 但是直接使用文件系統(tǒng)也可以??？
為什么要數(shù)據(jù)庫？ 還“關(guān)系”？
不，我能活這么久，是有一些獨(dú)門秘籍的。
1.我有著堅(jiān)實(shí)的數(shù)學(xué)基礎(chǔ)
這可真不是我吹牛，我的身上處處顯示著高貴的數(shù)學(xué)身影：
域，關(guān)系，笛卡爾積
關(guān)系代數(shù)：選擇，投影，連接
......
對了，你知道啥叫“關(guān)系”嗎？ 面試官如果問你的話你該如何回答？
其實(shí)所謂關(guān)系，在數(shù)學(xué)上的定義就是笛卡爾積的一個(gè)子集。
例如有兩個(gè)集合：
- s1 ={a,b}
- s2 = {1,2}
那s1和s2的笛卡爾積就是 ：
- s1 × s2 = {(a,1),(a,2),(b,1),(b,2)}
那么S 的任意一個(gè)子集都是關(guān)系：
{(a,1),(a,2)} 是一個(gè)“關(guān)系”
{(a,2), (b,1),(b,2)} 是另外一個(gè)“關(guān)系”
{(b,2)} 也是關(guān)系
......
如果你把s1和s2豎起來看，把s1看做列x能取值的集合， s2看做列y 能取值的集合， 那(x, y)它不就是一張表嗎？
我還有個(gè)很漂亮的性質(zhì)：
關(guān)系(表)經(jīng)過運(yùn)算以后，如select，join，where，交、并、差，結(jié)果還是一個(gè)關(guān)系（表）!
你看我的數(shù)學(xué)基礎(chǔ)是不是很牢靠？
2.我很直觀
至少表面上看起來是這樣的，如果你想給一個(gè)非計(jì)算機(jī)專業(yè)的人講解數(shù)據(jù)庫，可以和Excel類比下， 看看他能不能聽懂： 瞧， 這不就是個(gè)表格嗎，有行有列的。
3.使用簡單
這里不得不說說SQL這個(gè)優(yōu)秀的抽象層，它完全屏蔽了底層的實(shí)現(xiàn)細(xì)節(jié)，你完全不用考慮底層的文件是怎么存放的，只要發(fā)出SQL : SELECT ...... FROM ...... WHERE ...... 就好。
相比于早期復(fù)雜的層次狀，網(wǎng)狀數(shù)據(jù)庫， SQL實(shí)在是太簡單了。
不僅僅是開發(fā)人員，你們的業(yè)務(wù)人員稍加培訓(xùn)就可以寫SQL, 我清晰地記得有個(gè)業(yè)務(wù)分析師經(jīng)常去數(shù)據(jù)庫查數(shù)據(jù)，然后告訴程序員說數(shù)據(jù)不對，有Bug， 讓程序員非常頭疼。
4.對數(shù)據(jù)完整性的支持很好
我的每個(gè)字段都有確定的類型，還可以檢查數(shù)據(jù)的長度，取值范圍。
我的主鍵和外鍵，共同保證了數(shù)據(jù)的精確性和一致性， 防止數(shù)據(jù)的缺失。
5.我支持事務(wù)！
這可能是我能成功的一大關(guān)鍵了， ACID對于核心系統(tǒng)的數(shù)據(jù)（如銀行賬號）無比重要，不難想象一個(gè)轉(zhuǎn)賬操作沒有完成會帶來什么樣的影響。
6.范式
想要使用我們關(guān)系型數(shù)據(jù)庫，必須得遵守一定的規(guī)則，這些規(guī)則就是“范式”。
***范式是基本要求，即每個(gè)列都是不分割的數(shù)據(jù)項(xiàng)， 如果連這個(gè)都滿足不了，還是洗洗睡吧。
第二范式要求實(shí)體屬性要完全依賴主鍵，不能依賴部分主鍵。
第三范式就是一個(gè)表中不能包含其它表中已包含的非主關(guān)鍵字信息。不嚴(yán)謹(jǐn)?shù)卣f就是這個(gè)表只包含其他表的ID。
一般來說，你們都會遵循***和第二范式， 但是為了性能，為了避免過多的join, 有時(shí)候會違反第三范式，冗余一些字段的信息， 這我都可以理解。
7.大家用我做“數(shù)據(jù)的集成”
這是大牛Martin Fowler 提出的觀點(diǎn)：
企業(yè)級應(yīng)用程序居于一個(gè)豐富的生態(tài)系統(tǒng)中，它需要與其他應(yīng)用程序協(xié)同工作，而那些程序是由不同的團(tuán)隊(duì)合作開發(fā)出來的。
不同的應(yīng)用程序經(jīng)常要使用同一份數(shù)據(jù)， 而且某個(gè)應(yīng)用程序更新完數(shù)據(jù)以后，必須讓其他應(yīng)用程序知道這份數(shù)據(jù)已經(jīng)改變了。
采用”共享數(shù)據(jù)庫集成“ ，多個(gè)應(yīng)用程序都將數(shù)據(jù)保存在一個(gè)數(shù)據(jù)庫中，所有的應(yīng)用很容易就能使用彼此的數(shù)據(jù)了。
8.遺留數(shù)據(jù)
幾十年來，我這里積累了大量的應(yīng)用數(shù)據(jù)，雖然說城頭變幻大王旗，訪問關(guān)系數(shù)據(jù)庫的應(yīng)用程序變了好幾茬，編程語言也換了好幾波，但是關(guān)系數(shù)據(jù)庫中的數(shù)據(jù)巋然不動，他們的壽命遠(yuǎn)遠(yuǎn)超過應(yīng)用程序的壽命， 數(shù)據(jù)變成了一個(gè)企業(yè)寶貴的財(cái)富。
但是世界上沒有***的東西， 我雖然有眾多優(yōu)點(diǎn)， 但是也有不少缺點(diǎn)。
在互聯(lián)網(wǎng)時(shí)代， 在高并發(fā)，大流量的映襯下，這些缺點(diǎn)顯得格外刺眼：
對分布式系統(tǒng)支持不好, 難于組成集群，水平擴(kuò)展比較難。
復(fù)雜的類型（XML、JSON等）不好表達(dá)。
應(yīng)對互聯(lián)網(wǎng)的海量請求力不從心。
......
為了應(yīng)對這些問題，你們?nèi)祟惪梢哉f是想了很多辦法，比如什么NoSQL數(shù)據(jù)庫，什么分庫分表，在比如你們發(fā)展了BASE理論，不追求ACID中的強(qiáng)一致性，只要達(dá)到“基本可用”，最終一致性就可以了。
但是我不得不說，對于核心的數(shù)據(jù)，交由我來保管才是正道。
我已經(jīng)快50了，不知道能不能再活50年，但是再活20年我覺得是沒問題的，所以，我建議你還是好好學(xué)習(xí)一下吧。
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號coderising獲取授權(quán)】
