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

轉(zhuǎn)載于:https://blog.51cto.com/aliapp/1325391

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。