資料庫物理模型設計的其他模式之自聯結模式

**之8

（二）自聯結模式

自聯結模式，也可以看作是「主從模式」的一種特殊情況（或者說是「變形」），它在一張表內實現了「一對多關係」，並且可以根據業務需要實現「有限層」或者「無限層」的主從巢狀。

這種模式用得最多的情況就是實現「樹形結構」資料的儲存，比如各大**上常見的細分類別、應用系統的組織結構、web系統的選單樹等都能用到這種模式。

自聯結模式有很多變體，且每種變體的優缺點同樣鮮明。由於本**的重點在於對跨行業通用資料庫模型設計進行分析，所以對每種具體模式的細節方面的設計技巧不能作詳細論述，請大家原諒。這裡僅舉兩個例子說明：

1.簡單自聯結

簡單自聯結，就是在乙個表裡設定當前類id、父類id，同時規定最頂層類的父類id為乙個固定值（比如0），在生成樹的時候使用遞迴演算法，記錄的前後順序通過「排序號」欄位來確定。

這個表用來儲存選單樹很方便。首先會有乙個主選單，主選單下有子選單，子選單下面又有孫選單……選單的數量不確定、層級不確定，使用者可以在任意選單下增加新的子選單，或者刪除某個子選單及其下的所有孫選單……這種設計方式很多人都會用到，短小精悍、維護方便、且完全滿足使用者需求，而且樹的層次不限，擴充套件起來非常容易。這些都是它的優點。

它的缺點就是樹結構的生成由於使用了遞迴演算法，必然要對該錶進行多次讀取（讀取的次數 = 表內的記錄數 – 最深層級的記錄數），多次讀取就來了比較低的執行效率，當表裡的記錄很多的時候，這個缺點可以稱得上是致命的。

於是就有了下面的這種設計模式。

2.擴充套件自聯結

擴充套件自聯結，與簡單自聯結的最大區別就是通過附加冗餘欄位來避免遞迴運算，所要實現的主要目標就是一次讀取就能生成整個樹，一次提高樹的生成效率。

但是，魚與熊掌不可兼得，凡事都有兩面性。

生成樹的效率提高了，增刪改表內記錄的演算法就會相應複雜，並且樹的層數也變為有限的了。

所以在此類設計的時候，大家還是要認真分析業務需求，看看實際業務的重點在什麼地方，然後再作具體設計。比如一些門戶**在首頁顯示產品類別是業務重點，那麼我們在設計的時候就要盡可能的提高生成樹的效率，採取擴充套件自聯結模式；相反，一些基於web的業務系統，要求對選單樹的增刪改維護操作盡量簡單，由於選單的數目不多，所以選單樹的生成效率不是瓶頸，那麼我們設計的時候就可以採取簡單自聯結模式。

在這裡僅舉乙個例子如下：

這個設計與前面的設計最大的區別就是排序字段，前面的簡單自聯結用了乙個整數型的字段來實現排序，這裡用了乙個varchar20型的字段「層級**」來實現大排序。這個欄位的取值兩位一組，代表一層，假定最深為5層，初始值為0000000000。

按照這樣的設計，表內的資料記錄可能就是這樣的： id

typename parentid typelevel 1

根類別

0 000000 2

類別1

1 010000 3

類別1.1

2 010100 4

類別1.2

2 010200 5

類別2

1 020000 6

類別2.1

5 020100 7

類別3

1 030000 8

類別3.1

7 030100 9

類別3.2

7 030200 10

類別1.1.1

3 010101 ……

現在按typelevel欄位進行排序，執行如下sql語句：select * from tmp_type order by typelevel

列出記錄集如下： id

typename parentid typelevel 1

總類別

0 000000 2

類別1

1 010000 3

類別1.1

2 010100 10

類別1.1.1

3 010101 4

類別1.2

2 010200 5

類別2

1 020000 6

類別2.1

5 020100 7

類別3

1 030000 8

類別3.1

7 030100 9

類別3.2

7 030200 ……

在控制顯示類別的層次時，只要對「層級**」欄位中的數值進行判斷，每2位一組，如大於0則向右移2個空格。

資料庫物理模型設計的其他模式之自聯結模式

資料庫物理模型設計的其他模式

資料庫物理模型設計的其他模式之自聯結模式

資料庫設計之概念 邏輯 物理模型

相關推薦

資料庫設計之概念邏輯物理模型