樹形結構的數據庫表Schema設計-基於左右值編碼

樹形結構的數據庫表Schema設計算法


    程序設計過程當中,咱們經常用樹形結構來表徵某些數據的關聯關係,如企業上下級部門、欄目結構、商品分類等等,一般而言,這些樹狀結構須要藉助於數據庫完 成持久化。然而目前的各類基於關係的數據庫,都是以二維表的形式記錄存儲數據信息,所以是不能直接將Tree存入DBMS,設計合適的Schema及其對 應的CRUD算法是實現關係型數據庫中存儲樹形結構的關鍵。sql

    理想中樹形結構應該具有以下特徵:數據存儲冗餘度小、直觀性強;檢索遍歷過程簡單高效;節點增刪改查CRUD操做高效。無心中在網上搜索到一種很巧妙的 設計,原文是英文,看事後感受有點意思,因而便整理了一下。本文將介紹兩種樹形結構的Schema設計方案:一種是直觀而簡單的設計思路,另外一種是基於左 右值編碼的改進方案。數據庫

1、基本數據緩存

    本文列舉了一個食品族譜的例子進行講解,經過類別、顏色和品種組織食品,樹形結構圖以下:ide

 

2、繼承關係驅動的Schema設計函數

    對樹形結構最直觀的分析莫過於節點之間的繼承關係上,經過顯示地描述某一節點的父節點,從而可以創建二維的關係表,則這種方案的Tree表結構一般設計爲:{Node_id,Parent_id},上述數據能夠描述爲以下圖所示:性能


    這種方案的優勢很明顯:設計和實現天然而然,很是直觀和方便。缺點固然也是很是的突出:因爲直接地記錄了節點之間的繼承關係,所以對Tree的任何 CRUD操做都將是低效的,這主要歸根於頻繁的「遞歸」操做,遞歸過程不斷地訪問數據庫,每次數據庫IO都會有時間開銷。固然,這種方案並不是沒有用武之 地,在Tree規模相對較小的狀況下,咱們能夠藉助於緩存機制來作優化,將Tree的信息載入內存進行處理,避免直接對數據庫IO操做的性能開銷。優化

3、基於左右值編碼的Schema設計ui

    在基於數據庫的通常應用中,查詢的需求總要大於刪除和修改。爲了不對於樹形結構查詢時的「遞歸」過程,基於Tree的前序遍歷設計一種全新的無遞歸查詢、無限分組的左右值編碼方案,來保存該樹的數據。編碼


    第一次看見這種表結構,相信大部分人都不清楚左值(Lft)和右值(Rgt)是如何計算出來的,並且這種表設計彷佛並無保存父子節點的繼承關係。但當 你用手指指着表中的數字從1數到18,你應該會發現點什麼吧。對,你手指移動的順序就是對這棵樹進行前序遍歷的順序,以下圖所示。當咱們從根節點Food 左側開始,標記爲1,並沿前序遍歷的方向,依次在遍歷的路徑上標註數字,最後咱們回到了根節點Food,並在右邊寫上了18。

    第一次看見這種表結構,相信大部分人都不清楚左值(Lft)和右值(Rgt)是如何計算出來的,並且這種表設計彷佛並無保存父子節點的繼承關係。但當 你用手指指着表中的數字從1數到18,你應該會發現點什麼吧。對,你手指移動的順序就是對這棵樹進行前序遍歷的順序,以下圖所示。當咱們從根節點Food 左側開始,標記爲1,並沿前序遍歷的方向,依次在遍歷的路徑上標註數字,最後咱們回到了根節點Food,並在右邊寫上了18。

    依據此設計,咱們能夠推斷出全部左值大於2,而且右值小於11的節點都是Fruit的後續節點,整棵樹的結構經過左值和右值存儲了下來。然而,這還不夠,咱們的目的是可以對樹進行CRUD操做,即須要構造出與之配套的相關算法。

 4、樹形結構CRUD算法

(1)獲取某節點的子孫節點

    只須要一條SQL語句,便可返回該節點子孫節點的前序遍歷列表,以Fruit爲例:SELECT* FROM Tree WHERE Lft BETWEEN 2 AND 11 ORDER BY Lft ASC。查詢結果以下所示:

    那麼某個節點到底有多少的子孫節點呢?經過該節點的左、右值咱們能夠將其子孫節點圈進來,則子孫總數 = (右值 – 左值– 1) / 2,以Fruit爲例,其子孫總數爲:(11 –2 – 1) / 2 = 4。同時,爲了更爲直觀地展示樹形結構,咱們須要知道節點在樹中所處的層次,經過左、右值的SQL查詢便可實現,以Fruit爲 例:SELECTCOUNT(*) FROM Tree WHERE Lft <= 2 AND Rgt >=11。爲了方便描述,咱們能夠爲Tree創建一個視圖,添加一個層次數列,該列數值能夠寫一個自定義函數來計算,函數定義以下:

[sql]  view plain copy
 
  1. CREATEFUNCTION int RETURNSint AS begin declareint set declareint declareint selectfromwhere begin selectfromwhere select(*) fromwhere Rgt >= @rgt  
  2. end return end GO  

    基於層次計算函數,咱們建立一個視圖,添加了新的記錄節點層次的數列:

[sql]  view plain copy
 
  1. CREATEVIEW AS SELECTNameASFROMORDERBY GO  

    建立存儲過程,用於計算給定節點的全部子孫節點及相應的層次:

[sql]  view plain copy
 
  1. CREATEPROCEDURE int AS declareint declareint selectfromwhere begin selectfromwhere selectfromwhere @lft  @rgt orderbyASC end GO  

    如今,咱們使用上面的存儲過程來計算節點Fruit全部子孫節點及對應層次,查詢結果以下:

 


 

    從上面的實現中,咱們能夠看出採用左右值編碼的設計方案,在進行樹的查詢遍歷時,只須要進行2次數據庫查詢,消除了遞歸,再加上查詢條件都是數字的比 較,查詢的效率是極高的,隨着樹規模的不斷擴大,基於左右值編碼的設計方案將比傳統的遞歸方案查詢效率提升更多。固然,前面咱們只給出了一個簡單的獲取節 點子孫的算法,真正地使用這棵樹咱們須要實現插入、刪除同層平移節點等功能。

 (2)獲取某節點的族譜路徑

    假定咱們要得到某節點的族譜路徑,則根據左、右值分析只須要一條SQL語句便可完成,以Fruit爲例:SELECT* FROM Tree WHERE Lft < 2 AND Rgt > 11 ORDER BY Lft ASC ,相對完整的存儲過程:

[sql]  view plain copy
 
  1. CREATEPROCEDURE int AS declareint declareint selectfromwhere begin selectfromwhere selectfromwhere Rgt > @rgt orderbyASC end GO  

(3)爲某節點添加子孫節點

    假定咱們要在節點「Red」下添加一個新的子節點「Apple」,該樹將變成以下圖所示,其中紅色節點爲新增節點。


 

    仔細觀察圖中節點左右值變化,相信你們都應該可以推斷出如何寫SQL腳本了吧。咱們能夠給出相對完整的插入子節點的存儲過程:

[sql]  view plain copy
 
  1. CREATEPROCEDURE int varchar AS declareint selectfromwhere begin SETON BEGIN selectfromwhere updatesetwhere updatesetwhere insertintoNamevalues COMMITTRANSACTION SETOFF end GO  

(4)刪除某節點

    若是咱們想要刪除某個節點,會同時刪除該節點的全部子孫節點,而這些被刪除的節點的個數爲:(被刪除節點的右值 – 被刪除節點的左值+ 1) / 2,而剩下的節點左、右值在大於被刪除節點左、右值的狀況下會進行調整。來看看樹會發生什麼變化,以Beef爲例,刪除效果以下圖所示。

    則咱們能夠構造出相應的存儲過程:

[sql]  view plain copy
 
  1. CREATEPROCEDURE int AS declareint declareint selectfromwhere begin SETON BEGIN selectfromwhere deletefromwhere Rgt <= @rgt  
  2. updatesetwhere updatesetwhere COMMITTRANSACTION SETOFF end GO  

5、總結

    咱們能夠對這種經過左右值編碼實現無限分組的樹形結構Schema設計方案作一個總結:

    (1)優勢:在消除了遞歸操做的前提下實現了無限分組,並且查詢條件是基於整形數字的比較,效率很高。

    (2)缺點:節點的添加、刪除及修改代價較大,將會涉及到表中多方面數據的改動。

    固然,本文只給出了幾種比較常見的CRUD算法的實現,咱們一樣能夠本身添加諸如同層節點平移、節點下移、節點上移等操做。有興趣的朋友能夠本身動手編 碼實現一下,這裏不在列舉了。值得注意的是,實現這些算法可能會比較麻煩,會涉及到不少條update語句的順序執行,若是順序調度考慮不周詳,出現 Bug的話將會對整個樹形結構表產生驚人的破壞。所以,在對樹形結構進行大規模修改的時候,能夠採用臨時表作中介,以下降代碼的複雜度,同時,強烈推薦在 作修改以前對錶進行完整備份,以備不時之需。在以查詢爲主的絕大多數基於數據庫的應用系統中,該方案相比傳統的由父子繼承關係構建的數據庫Schema更 爲適用。

參考文獻:《Storing Hierarchical Data in a Database Article》

轉載:http://blog.csdn.net/dreajay/article/details/8894058

相關文章
相關標籤/搜索