關鍵詞：互聯網、關系型數據庫
強調互聯網，這是因為本文所討論的前提是互聯網應用。與“傳統”應用不同，互聯網中的應用每天面臨的是海量的數據、大量的請求以及對系統可靠性和響應速度有着更高的要求。“傳統”應用，我姑且淺顯地認為是，數據量不大，面對的用戶群范圍相對較小，自然大量的高並發請求場景幾乎不存在。
在上文對互聯網應用和傳統應用有了一個大概的認識后，接下來我們來談一談，本文的主題關系型數據庫在兩種類型應用的不同使用方式，以及關系型數據在如今的互聯網應用中是否不再是關注的焦點。
首先，海量的數據。百萬級甚至千萬級億級的數據已不可能存儲在單一的數據表中，甚至不可能存儲在一個數據庫中。試想如果將所有的數據存儲在單庫單表中，一旦發生全表掃描，這對於系統響應速度來講將是一個災難。然而在傳統應用中，可能單庫單表已經足以適用。
第二，由於產生了海量數據，進而數據在磁盤上的存儲被設計成了“分庫分表”的模式，利用某種特定的“路由”算法，定位一個數據所處的位置。正是因為“分庫分表”的設計，使得關系型數據中的“聯表查詢”場景失效，所以在互聯網應用中，一張表的設計已經幾乎不再有“外鍵”，也就是聯表查詢幾乎已消失。
第三，大量的請求。這在互聯網應用中比較常見，一起突發事件，一個明星的突發新聞，都會造成大量的請求瞬時到達。數據庫的承載能力是有限的，一旦所有的訪問量在某一時刻同時涌入，這直接會造成數據庫宕機，整個系統甚至會因為數據庫的原因造成服務不可用。所以在如今的互聯網應用中，對數據的讀取寫入幾乎已經不再直接操作數據庫，而是在數據庫前加入了一道“安全”屏障——緩存。
第四，服務的可靠性。服務的可靠性，即使系統出現問題，也要保證部分可用，讀寫分離是一個很好的解決方案，讀取和寫入操作不再同一個數據庫中進行，而是將他們分開。如果此時有大量寫操作，要盡量不影響讀操作，或者如果如果在寫入數據庫時造成數據庫宕機，此時要盡量不能影響數據庫的讀操作。此時在互聯網應用中通常就會部署一套“主從”數據庫，主庫寫，從庫讀，這就會衍生出數據同步的問題，或者歸納為數據一致性問題。
可以看到，互聯網應用與傳統應用的異同點在於，互聯網應用對於數據庫的着重點在於從整體上進行把握，對數據的操作相對來說比較“粗糙”。而傳統應用由於其自身原因，只需要考慮更為“精細化”的操作，例如連表查詢，表與表的關系，關系表還是實體表等等。
這是否意味着，在互聯網中關系型數據庫已經不再那么重要了呢？那些課本上的第一范式、第二范式已經過時了呢？
如果認為互聯網中關系型數據庫不再強調“精細化”的操作，就是已經過時了，這是一葉障目不見泰山。再總結一下，在互聯網中，對於關系型數據庫，我們需要設計分庫分表、主從庫、讀寫分離、熱點數據緩存等等。在傳統應用中，對於關系型數據庫，我們需要設計出E-R圖，需要設計主鍵、外鍵，需要寫聯表查詢的SQL語句等等。
再回顧一下，我們在大學的數據庫課程中，在學習數據庫時，是否是從第一范式、第二范式開始的？再逐步練習“一個學生學習了哪幾門課程”、“一個學生每個課程的分數”、“某門課程按80分、90分以上分類”這類的SQL語句，因為這是基礎，這是原理。
那么回到本文的主題“在互聯網中關系型數據庫是否不再那么重要”，筆者的觀點是，側重點不同，互聯網應用的很大，有的很大很大，有時需要你放棄遵循某些范式，從其他方面去彌補，而從整體上去思考如何進行數據建模，互聯網應用更加考驗的是“能力”，對數據建模的能力，如何構建更高的可靠性應用。傳統應用，更加考驗的是一切按照規矩來，“精細化”的操作，對SQL語句的熟悉程度就意味着對數據庫的熟悉程度。
但就算是互聯網中，SQL語句並非是不重要的，不要因為自己處在互聯網，不熟悉SQL語句當做是一種“炫耀”，這是扎馬步式的基本功。最簡單的例子，如果不重要，像阿里一樣的互聯網公司，照樣在研究關系型數據庫（參見：阿里巴巴數據庫內核月報： http://mysql.taobao.org/monthly/）。
最后，《三體》一書中，智子鎖死了人類的基礎物理學，導致人類在科技面前完全停滯。
這是一個能給程序員加buff的公眾號
