關系型數據庫為什么能活這么久？
我就是你們常用的關系型數據庫， IBM的研究員E.F.Codd 于1970年把我的理論帶到這個世界上，我已經快50歲了。
我的家族成員居住在世界各地性能強悍的服務器中， 保存著你們人類的大量珍貴的數據，從你的銀行余額，到你的購物清單，幾乎每一筆網上交易都有我們負責保存。
我是如此重要，幾乎每一位軟件從業者都需要認真學習，很多時候我都是存儲大量數據的***，你要做的，就是選擇一個我的家族成員而已，比如：Oracle, MySQL, Db2，SQL Server這些家伙。
對了，還有一個小巧玲瓏的SQLite，做手機端開發的離不開它。
在日新月異的IT界， 一門技術居然能存活這么久，實在是不可思議。
也許會有人想到這個問題： 你為什么能活這么久？
簡單地拍腦袋想一想，也許是我能夠大規模地保存和檢索數據？ 但是直接使用文件系統也可以啊？
為什么要數據庫？ 還“關系”？
不，我能活這么久，是有一些獨門秘籍的。
1.我有著堅實的數學基礎
這可真不是我吹牛，我的身上處處顯示著高貴的數學身影：
域，關系，笛卡爾積
關系代數：選擇，投影，連接
......
對了，你知道啥叫“關系”嗎？ 面試官如果問你的話你該如何回答？
其實所謂關系，在數學上的定義就是笛卡爾積的一個子集。
例如有兩個集合：
- s1 ={a,b}
- s2 = {1,2}
那s1和s2的笛卡爾積就是 ：
- 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獲取授權】
