本節書摘來自異步社區出版社《圖數據庫（第2版）》一書中的第2章，第2.1節，作者：【美】Ian Robinson（伊恩?羅賓遜） , Jim Webber（吉姆?韋伯） , Emil Eifrem（埃米爾?艾弗雷姆），更多章節內容可以訪問云棲社區“異步社區”公眾號查看。

2.1 關系型數據庫缺少聯系

數十年來，開發者試圖使用關系型數據庫處理關聯的、半結構化的數據集。關系型數據庫設計之初是為了處理紙質表格以及表格化結構—有些方面關系型數據庫做得非常好—它們試圖對這種實際中的特殊聯系進行建模。然而諷刺的是，關系型數據庫在處理聯系上做得卻并不好。

聯系確實存在于關系型數據庫自身的術語中，但只出現在建模階段，作為連接表的手段。前面章節在對關聯數據的討論中曾經提到，我們經常需要對連接實體的聯系進行語義的區分，并為其定義權重。關聯關系什么也做不了。更糟糕的是，隨著離群數據（outlier data）的成倍地增加，數據集的宏觀結構會越發復雜和不規整，關系模型將造成大量表連接、稀疏行和非空檢查邏輯。關系世界中連通性的增強都將轉化為連接操作的增加，這會阻礙性能，并使已有的數據庫難以響應變化的業務需求。

圖2-1展示了一個以客戶為中心的、事務型應用程序存儲顧客訂單的關系模式（relational schema）。

這種模式的設計對該應用程序產生了很大影響，使有些查詢非常簡單，而有些異常困難。

表連接增加了偶發復雜性，使得業務數據與外鍵元數據混雜起來。
外鍵約束增加了額外的開發與維護成本，而目的僅僅是為了讓數據庫工作。
帶有空值列的稀疏表在代碼中需要額外檢查，盡管模式本身提供了相關支持。
僅因為想要查看客戶買了什么就需要好幾個昂貴的連接。
反向查詢（reciprocal query）代價更高。查詢“某個客戶買了哪些商品？”比查詢“有哪些客戶買了某個商品？”的代價相對要低，而這是推薦系統的基礎。對于這樣的需求，可以引入索引，然而即使引入索引，隨著遞歸程度的增加，諸如“有哪些買這個商品的客戶也買了那個商品？”這樣的遞歸問題的查詢代價變得異常高昂。

關系型數據庫在強關聯領域表現也很掙扎。讓我們通過社交網絡領域中的一些或是簡單或是不那么簡單的查詢來理解關系型數據庫中關聯查詢的成本吧。

圖2-2展示了一個記錄朋友關系的簡單的連接表設計。

回答“誰是Bob的朋友？”這個問題很簡單，如示例2-1所示。

示例2-1　Bob的朋友

SELECT p1.Person FROM Person p1 JOIN PersonFriendON PersonFriend.FriendID = p1.ID JOIN Person p2ON PersonFriend.PersonID = p2.ID WHERE p2.Person = 'Bob'

基于這個示例數據，答案是Alice和Zach。這不是一個代價高昂或困難的查詢，因為它使用了WHERE Person.person='Bob'，使得返回的行數是可預期的和有限的。

朋友關系不總是自反關系（reflexive relationship），因此在示例2-2中，需要回答示例2-1的反向查詢：“Bob是誰的朋友？”

示例2-2　Bob是誰的朋友

SELECT p1.Person FROM Person p1 JOIN PersonFriendON PersonFriend.PersonID = p1.ID JOIN Person p2ON PersonFriend.FriendID = p2.ID WHERE p2.Person = 'Bob'

這個查詢的答案是Alice，很遺憾Zach不認為Bob是他的朋友。這個反向查詢在實現上也很簡單，但是數據庫端的花銷就略微大些了，因為所有的數據行都在表PersonFreiend中。

我們可以加入索引，然而仍會涉及代價高昂的中間層。當問題是“誰是我的朋友的朋友？”時就更麻煩了。SQL的層級結構使用了遞歸連接，使得查詢語法和計算都更加復雜，如示例2-3所示。（有些關系型數據庫提供這種查詢的語法糖。例如，Oracle提供了函數CONNECT BY，它可以簡化查詢語句，但并不能降低底層的計算復雜度。）

示例2-3　Alice的朋友的朋友們

SELECT p1.Person AS PERSON, p2.Person AS FRIEND_OF_FRIEND FROM PersonFriend pf1 JOIN Person p1ON pf1.PersonID = p1.ID JOIN PersonFriend pf2ON pf2.PersonID = pf1.FriendID JOIN Person p2ON pf2.FriendID = p2.ID WHERE p1.Person = 'Alice' AND pf2.FriendID <> p1.ID

即使只是處理Alice的朋友的朋友們，而非深入Alice的整個社交網絡，這個查詢計算也很復雜。當我們試圖探究社交網絡時，問題則更復雜，代價也更高。雖然“誰是我的朋友的朋友們？”這樣的問題還是可能在合理的時間內通過查詢得到答案，但是當查詢延伸到第4度、第5度或第6度的朋友關系時，由于遞歸的連表查詢使此時的時間空間復雜度非常高，從而使查詢的效率嚴重惡化。

無論試圖在關系型數據庫中對關聯建模還是查詢，結果都與我們的愿望完全不同。除了之前指出的查詢和計算復雜度以外，我們還得去處理模式（schema）這個雙刃劍。很多時候，模式被證明太死板、太脆弱。死板表現在：我們需要在創建稀疏表的同時在代碼中處理異常情況—一切只是因為沒有一個能夠容納我們所用到的各類數據的通用的模式。這在增加了耦合度的同時也摧毀了其貌似存在的凝聚力。脆弱表現在：當應用程序發生變化時，需要增加額外的工作從一個模式遷移到另一個模式。

總結

以上是生活随笔為你收集整理的《图数据库（第2版）》——2.1 关系型数据库缺少联系的全部內容，希望文章能夠幫你解決所遇到的問題。

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