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

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

來自:碼農翻身(微訊號: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)

分享創造快樂