數據庫的分層和網絡模型的問題究竟是什麼？

Question

在E F Codd 1970年發表他的論文「大型共享數據庫的數據的關係模型」之前，hierarchal和network是數據庫的兩個突出模型。

他們究竟錯了什麼，他們沒有獲勝？

Answer 1

基本問題是無法支持即席查詢。這些數據庫速度非常快，但只有當您以他們的原創設計師期望的方式查詢這些數據庫時。如果您想出另一種類型的查詢，它們可能會非常緩慢，或者最糟糕的情況是需要更改數據庫模式以支持查詢。

我在80年代（Codasyl和Nomad/2）實際上都在研究這兩種類型，並且當SQL變得更加廣泛時非常高興。

Answer 2

1. 沒有簡單的方法來生成報告
2. 剛性架構
3. 網絡模型是太相似了層次，所以它並沒有真正使用的網絡模型得到了實惠。而不是像層次模型那樣有一個單獨的父親，一個記錄可能有多個父母。所以一切仍然在父母/子女關係方面考慮。

這些模型的優點在於性能，這就是我認爲RDBMS佔據統治地位需要這麼長時間（他們一開始表現非常糟糕）。

如果你想深入挖掘歷史this採訪Charles Bachman強烈推薦閱讀！他也是一個有趣的人，實際上他編寫了第一個關於RDBMS的自動數據建模工具！

順便說一句，層次/網絡數據庫至少在大型機設置中仍在使用。

Answer 3

到目前爲止的答案涵蓋了網絡和層次模型最終被關係模型（包括SQL數據庫系統）取代的很多實際原因。 Codd 1970年的論文詳細解釋了爲什麼需要新模型。這是一個很棒的閱讀。事實上，在Codd之前，「數據模型」這個術語實際上聞所未聞。所以他創造了「分層模型」和「網絡模型」這兩個術語來描述那些沒有精確模型構建的數據庫系統。

可以將分層和網絡模型收集到一個通稱中，稱爲「圖模型」。數據圖模型的基本特徵是數據項通過陳述它們的位置來引用。如果你理解指針，你就會理解關於圖模型的一切基本知識。

數據圖模型有兩個非常強大的優勢。首先，程序員很容易掌握。新手程序員通過一定的學習曲線來掌握指針，但一旦他們完成了這些，他們已經準備好輕鬆理解圖形數據。

第二個優點是指針非常快，只要在數據寫入時預計要遵循的導航路徑。

使用指針來識別數據有幾個缺點。一個是數據變得「固定」。也就是說，當數據被混洗時，所有引用數據的指針必須被定位和更新。或者「轉發地址」必須留在舊的位置。如果你曾經在網絡中點擊過一直運行的按鈕，只會遇到臭名昭着的「未找到頁面」錯誤，你可能遇到了洗牌固定數據的問題，而沒有更新對它的引用。

第二個問題是，導致數據沿着計劃外的訪問路徑在性能和邏輯正確性方面都可能是徹頭徹尾的災難。這是圖形數據庫特別報告如此困難的原因之一。

圖形數據的第三個缺點是圖形數據中可能存在邏輯關係，這些邏輯關係並不是給定的數據所固有的。關係模型的根本優勢在於所有關係都是數據本身固有的。這是一個優勢的原因很複雜。我再次提到你1970年的論文。在您和我可能使用的所有「關係數據庫管理系統」中，使用數據來識別數據和使用指針來定位數據之間有一個橋樑。它被稱爲索引。該索引與兩個項目相關：索引鍵（表中的一個或多個列）和一個指針（用於查找包含索引鍵的行）。我正在關注有關索引的所有細節。

反正索引允許SQL引擎翻譯，指出什麼數據正在尋求爲，其中尋找那些數據的查詢。索引指向的數據仍可能被混洗，但索引必須作爲過程的一部分重新構建。

這是一個概述。

Answer 4

導航。分層和網絡模型依賴於數據庫中的導航結構（又名指針/鏈接/圖形）。因此，它們的功能受到這些結構設計的限制。相比之下，關係模型「僅提供了一種用其自然結構描述數據的手段 - 也就是說，沒有爲機器表示目的疊加任何附加結構。」[1]

具有諷刺意味的是，目前的「NOSQL」趨勢數據庫也包含導航結構，經常查看它們（我錯誤地認爲）是解決SQL數據庫感知限制的一個很好的解決方案。

[1]「數據大型共享數據庫的關係模型」E.F.CODD，1970