歡迎光臨
每天分享高質量文章

關係型資料庫為什麼能活這麼久?

來自:碼農翻身(微信號:coderising)

我就是你們常用的關係型資料庫, 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年我覺得是沒問題的,所以,我建議你還是好好學習一下吧。


●編號331,輸入編號直達本文

●輸入m獲取文章目錄

推薦↓↓↓

 

運維

更多推薦18個技術類微信公眾號

涵蓋:程式人生、演算法與資料結構、黑客技術與網絡安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等

赞(0)

分享創造快樂