關係型資料庫建立在表格和資料列的基礎上，這種結構是為平面數據設計的。然而，現實世界很少遵循如此簡單的模式。組織、檔案系統、評論串列和分類樹都存在於層次結構。在標準實體關係圖（ERD）中表示這些父子關係，需要特定的設計模式，以在維持資料完整性之餘，實現高效檢索。
當你試圖將樹狀結構映射到平面結構時，會遇到規範化與效能之間的經典矛盾。本指南探討了建模層次數據的核心技術，評估每種方法的取捨，以協助你設計穩健的系統。
🧩 平面結構的挑戰
實體關係圖通常將實體以方框表示，關係以線條表示。在標準關係中，一個表格透過外鍵連結到另一個表格。這在多對多或一對多且方向固定的場景中運作得完美無缺。但當一個分類可以擁有子分類，子分類又可擁有孫分類，甚至無限延伸時，會發生什麼情況？
標準的關係模型難以處理變化的深度。平面表格無法輕易儲存任意長度的路徑。為了解決此問題，我們必須調整資料結構，以明確儲存層次關係。資料架構師常用以下三種主要模式來達成此目的：
- 鄰接清單： 在子記錄中儲存父節點的ID。
- 巢狀集合： 為定義範圍而分配左值和右值。
- 路徑枚舉： 儲存從根節點到目前節點的完整路徑。
🔗 鄰接清單模型
鄰接清單是標準ERD中表示層次結構最常見且最直接的方法。它依賴於自我引用的關係。這表示單一表格中包含一個欄位，引用其自身的主鍵。
📐 資料結構
在此模型中，你建立單一表格來儲存資料。每一列代表樹中的節點。關鍵的新增欄位通常命名為parent_id或ancestor_id，用來儲存父節點的唯一識別碼。若節點位於層次結構的頂端，此欄位則包含空值。
考慮一個用於部門:
- id： 部門的唯一主鍵。
- name： 部門的顯示名稱。
- parent_id： 上級部門的ID（頂層為可空）。
✅ 優點
- 簡單性： 該資料結構直觀且對開發人員和資料庫管理員而言容易理解。
- 彈性：移動子樹非常簡單；您只需更新
parent_id該子樹根節點的。 - 規範化： 由於資料不會重複，因此能很好地符合第三範式（3NF）。
❌ 缺點
- 查詢複雜度： 檢索所有後代節點需要遞迴查詢或應用層處理。
- 效能： 若無特定索引策略或遞迴公用表表達式（CTEs），深度遍歷可能較慢。
- 參考完整性： 雖然外鍵有助於維護，但如果約束未嚴格執行，仍可能出現循環引用。
🌲 內嵌集合模型
內嵌集合模型將樹狀結構轉換為一組區間。與追蹤父節點指標不同，每個節點會被分配兩個數字：left 和 right。這些值代表節點在樹的前序遍歷中的位置。
📐 資料結構
想像一棵樹，其中根節點代表整個集合。當您遍歷樹時，會遞增一個計數器。當您進入一個節點時，將目前的計數記錄為left。當您完成處理該節點及其所有子節點後，將計數記錄為right。其中right 值始終大於 左 值。
一個 類別 表格看起來像這樣：
- id： 唯一識別碼。
- 名稱： 類別名稱。
- lft： 左邊界值。
- rgt： 右邊界值。
✅ 優點
- 快速檢索： 取得子樹僅需使用
BETWEEN邏輯的簡單範圍查詢。 - 效率： 與鄰接清單相比，對於大型且深度的樹狀結構，讀取效能更優異。
❌ 缺點
- 寫入成本： 插入或移動節點的成本很高。您必須更新
lft和rgt許多其他節點的值，以維持區間的完整性。 - 複雜度： 若無專用程式庫支援，此邏輯難以實作與除錯。
🛣️ 路徑枚舉與物化路徑
路徑枚舉方法將節點的血統儲存為字串或以分隔符號分隔的清單。這種方法通常稱為物化路徑模式。它結合了鄰接清單的簡單性與路徑的可讀性。
📐 資料結構
在此模型中，每個記錄都儲存從根節點開始的完整路徑。例如，在檔案系統模型中，一個檔案可能具有類似於的路徑字串/home/user/documents/report.txt。在資料庫中，這通常以欄位內的分隔字串形式儲存，例如1/5/12/.
表格包含：
- id： 主鍵。
- 路徑： 代表血統的字串。
- 深度： 表示節點深度的整數。
✅ 優點
- 容易遍歷： 您可以透過比對路徑前綴來找到所有後代節點。
- 可讀性： 資料具有可讀性，且容易除錯。
- 排序： 依據路徑字串進行排序，通常能自然地產生正確的樹狀順序。
❌ 缺點
- 儲存空間開銷： 長路徑可能消耗大量的儲存空間。
- 字串解析： 查詢通常需要字串操作函數，這可能比整數比較更慢。
📊 比較分析
選擇合適的模型在很大程度上取決於您的讀取與寫入比率以及層級的深度。下表概述了每種方法的特徵。
| 功能 | 鄰接列表 | 巢狀集合 | 物化路徑 |
|---|---|---|---|
| 讀取效能 | 低至中等 | 高 | 中等至高 |
| 寫入效能 | 高 | 低 | 中等 |
| 實作複雜度 | 低 | 高 | 中等 |
| 支援深層樹狀結構 | 是 | 是 | 是（有限制） |
| 查詢邏輯 | 遞迴 | 範圍掃描 | 前綴匹配 |
⚙️ 性能考量
在建立層次結構模型時，必須考慮資料庫引擎如何處理資料。無論選擇哪種模型，索引策略都扮演著關鍵角色。
- 鄰接列表： 對
parent_id欄位進行大量索引。這使得資料庫能夠快速定位特定節點的所有子節點，而無需掃描整個資料表。 - 巢狀集合： 同時索引兩者
lft和rgt。複合索引可以顯著優化範圍查詢。 - 物化路徑： 索引
路徑欄位。根據資料庫的不同，前綴索引可能有利於過濾子樹。
🛠️ 維護與更新
資料模型並非靜態的。隨著您的組織擴張，您的層級結構將會改變。將一個節點從一個分支移動到另一個分支是一項常見的操作，但對每個模型的影響各不相同。
🔄 移動節點
在 鄰接清單中，移動一個節點僅需單一更新語句。您只需更改子樹根節點的 parent_id值。然而，您必須確保不會產生循環引用。
在 嵌套集合模型中，移動一個節點相當複雜。這需要重新計算所有位於目標子樹中的節點的 lft 和 rgt值，為移動的節點騰出空間。這通常是一個涉及多個表格更新的交易操作。
在 物化路徑模型中，您需更新移動節點及其所有後代的路徑字串。這需要為每個子節點更新路徑，對於大型樹結構而言，這可能是一項繁重的寫入操作。
🎯 資料模型設計的最佳實務
為確保您的實體關係圖（ERD）保持可維護且高效，實施層級結構時請遵循以下指南。
- 使用明確的命名規範： 避免使用像這樣的通用名稱
col1。請使用parent_id,ancestor_id,lft，或rgt明確地。 - 強制約束： 使用資料庫約束來防止循環引用。節點不能是自身的祖先。
- 限制深度： 雖然技術上可行，但極其深層的層次結構（例如超過10層）通常表示設計上有缺陷。如果可能，請考慮扁平化結構。
- 記錄選擇： 由於這些模式並非標準的SQL功能，請在資料庫結構文件中記錄所使用的模式。
- 考慮混合方法： 某些系統結合鄰接清單與物化路徑，以平衡讀取和寫入效能。
🧠 選擇正確的策略
並非每個情境都有單一的「正確」答案。決策取決於您應用程式的具體需求。
- 若符合以下情況，請選擇鄰接清單： 您的資料經常變動，且層次深度適中。這對於大多數通用應用程式來說是最安全的預設選擇。
- 若符合以下情況，請選擇巢狀集合： 您的應用程式以讀取為主，資料很少移動，且需要快速取得大型子樹。
- 若符合以下情況，請選擇物化路徑： 您需要人類可讀的路徑（例如URL），且層次深度相對較淺。
理解這些結構上的細微差別，能讓您設計出可擴展的資料庫。透過為您的實體關係圖選擇合適的模式，可確保資料在系統整個生命周期中保持一致、可存取且高效。