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

2021-04-08 14:31:03 字數 2459 閱讀 9592

(二)自聯結模式

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

這種模式用得最多的情況就是實現「樹形結構」資料的儲存,比如各大**上常見的細分類別、應用系統的組織結構、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個空格。  

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

之7 資料庫物理模型設計的其他模式 除了上面提到的四種主要設計模式,還有一些其他模式,在某些專案中可能會用到,在這裡先簡單做個說明,暫不做深入討論,等到以後的專案用到這些模式的時候,再結合實際需求詳細解說。一 繼承模式 繼承模式,可以看作是 主從模式 的一種特殊情況 或者說是 變形 它所代表的兩個物...

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

之8 二 自聯結模式 自聯結模式,也可以看作是 主從模式 的一種特殊情況 或者說是 變形 它在一張表內實現了 一對多關係 並且可以根據業務需要實現 有限層 或者 無限層 的主從巢狀。這種模式用得最多的情況就是實現 樹形結構 資料的儲存,比如各大 上常見的細分類別 應用系統的組織結構 web系統的選單...

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

在寫文件的資料庫設計說明書時,其中有結構設計,就是概念模型 邏輯模型 物理模型。關於這三個模型沒有什麼概念,只記得在資料庫這本書上見過,然後經過查閱之後得出這樣的結論 概念模型 對真實世界中問題域內的事物的描述,不是軟體設計的描述。表示概念模型最常用的是 實體 關係 圖 e r圖主要由實體 矩形 屬...