自從NoSQL概念橫空出世，關系數據庫似乎就成了眾矢之的，似乎一夜之間，關系數據庫和SQL就成了低效，高成本，速度慢的數據處理模式的代名詞。在很多地方都能看到類似：”我的項目初創，應該選擇什么NoSQL產品才能快速的開發？”這樣的問題。正因有人提出這樣的問題，才堅定了我把這篇文章放在了第一章的決心。主要的目標是希望借助這樣一個形式，讓大家能夠比較清晰的認識到類似NoSQL,SchemaFree,RDBMS,CAP,BASE等等概念的本源，并了解到他們面對的主要場景，從而避免亂花漸入迷人眼的尷尬，知其然而知其所以然。其實，軟件中所謂的對象，結構體，實體，關系等概念，都只是對現實生活中的一種抽象。因為人類太過渺小，渺小到無法真正的理解和模擬這個世界，所以不得不創造出一些概念，過濾掉具體的細節而只關心他們所需要關心的事情。這就產生了各種各樣的抽象。而SQL和關系模型，就是針對數據之間的“關系”而進行的一種抽象。簡單來說，他將一切事物都抽象為關系，并通過集合運算的方式規定了關系之間的運算過程，也因此更為嚴謹。比如，描述一輛車有四個輪子和四扇玻璃，那么就可以建立三張表格，一張存車的屬性，一張存玻璃的屬性，一張存輪子的屬性，并且在輪子和玻璃的表格中，冗余車的唯一標示。這樣就可以完成關系描述。如果要讀取車A.id=5車子的左前方輪子的出廠號碼標示，做法一般是：查詢輪子表，找到車子id=5的并且標有左前方屬性的那行數據，讀取他的出廠號碼。了解了關系模型，我們再來看看在關系模型產生之前，大家經常使用的層次模型吧。層次模型其實也是非常簡單的一類描述，還以車為例，一輛車有唯一的標示（可以是個id,也可以只是個入口引用），然后車節點有兩個子節點，一個是輪子集合節點，一個是玻璃集合節點，然后，輪子集合節點有四個節點，分別表示四個輪子，而玻璃集合有四個節點，分別標示四扇玻璃。如果要讀取車A.id=5車子的左前方輪子的出廠號碼標示，做法一般是：找到頂節點車A，然后查找該節點的子節點，輪子集合節點，然后遍歷4個子節點，找到標有左前方屬性的車輪，讀取其出廠號碼。從上面簡單的例子對比來看，相信大家立刻就能看出關系模型與傳統的層次or表格模型的最大差別。也就是用戶不再需要關注從車->輪子集合->輪子本身，這個存取路徑，只需要關注于核心的查詢邏輯(車子id=5,車輪屬性是左前方），就可以立刻找到數據了。使用關系模型，因為模型相對的比較簡單，并且數學證明比較嚴密，所以很快被大家接受。因此在市面上已經很少出現層次模型or網狀模型了。在互聯網時代之前，數據庫的研究領域更多的集中在關系模型與前端業務開發模型不匹配這個問題上，眾所周知的，在面向對象的語言產生之后，繼承，多態，充血模型已經成為了程序語言的標配，我們在這里不去討論是面向對象好，還是函數式編程好這樣沒結論的問題，只來簡單的瀏覽一下面向對象與關系模型的阻抗失配問題即可。如果大家寫過業務邏輯，一定也會覺得把數據庫里的數據轉變為程序對象是一件蛋疼無比的事情吧。將面向對象里面的繼承和組合這類概念硬套到關系數據庫上，需要耗費比較大的精力才能完成。為了解決這些問題，一種思路是在程序層做這個ORMapping的轉換，這類工具主要是hibernate、ibatis等工具。另外一個思路是在數據庫層面做這件事，比如oracle一直宣傳自己是ORDBMS。甚至甚至，連腳本語言框架比如ROR,django的核心目標之一也就是解決這個阻抗失配的問題~因為類似java/c++/.net這樣的語言是靜態編譯的，所以就必須要求用戶要在代碼中明確的定義對象的屬性名字和類型，而在數據庫內，也有一套對應的列名和數據庫類型信息。一張表有50多個字段，每次字段變更，都必須保證用戶代碼內的對象內的屬性和數據庫中的數據準確對應。這非常消耗時間，也非常容易錯。為了解決這個問題，要么是從程序代碼生成關系模型，要么是從關系模型反向生成程序代碼。這兩種方式都會面臨程序邏輯與關系模型不匹配的問題，于是寫ORMapping就成了一件蛋疼無比但又不得不做的事情。為了自動化，有大量的工具組件出現在這里，比如hibernate，比如ibatis，他們主要作用就是將我們的對象模型轉換為關系模型，不過這類工具最大的問題就是，學習工具本身的成本很高，甚至高于自己去做對象關系映射本身，而且經常會因為對ORMapping掌握的不夠精深，造成很多低效的查詢，拖慢了整體性能的問題。還有一些人為了偷懶，放棄使用對象bean來表示數據庫中數據。他們一般會采用Map映射來表示數據庫中一行數據，使用這種方式，Map的key就是列的名字，value就是列的值，如果要表示多行數據，那么就是一個List<Map>的結構。使用這種結構，程序就可以自動的根據數據庫給出的列名原信息來自動生成Map結構。但這種方式的問題是，丟失了面向對象所帶來的良好的封裝特性，經過多層傳遞與處理后，用戶很難辨識哪些是數據中間過程數據，哪些是數據庫原始數據。數據Map對象會膨脹的非常厲害，以至于無法管理。腳本語言的核心目標之一也就是解決這個阻抗失配的問題，腳本語言因為是動態編譯的，所以動態對一個對象增加或減少屬性變得非常簡單而清晰，所以對象內的數據可以直接根據數據庫內的數據進行內省獲得，不在需要人工維護，同時又不會出現因為Map結構所導致的代碼結構不清晰的問題，所以ROR這類的工具可以直接進行對象關系映射，極大地提升了小業務系統的生產力。可惜，對象數據庫和xml數據庫，都沒有形成一統天下的新浪潮，一直不瘟不火的緩慢發展著。隨著互聯網的爆發式發展，數據庫概念領域又一次發生了搖擺，伴隨著互聯網的特殊需求，一批有著新鮮血液的NoSQL數據庫涌現了出來，層次模型又從封印中蘇醒，站在了大家面前。這里就自然而然會有一系列的疑問產生了出來，為什么層次模型變種的NoSQL會出現并得到了一些人的認同？他滿足了什么需求？關系模型在什么地方不能滿足大家的需求了？那么，我們就從應用場景出發，嘗試回答一下這些問題吧。

轉載于:https://blog.51cto.com/aliapp/1325391

總結

以上是生活随笔為你收集整理的从需求出发来看关系模型与非关系模型–关系模型与非关系模型概述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。