個人博客:http://www.80soho.com/?p=781
場景:
有這麼個需求:設計開發一個評論系統,要求用戶可以評論文章以及相互回覆,無層級數限制。
這個需求開發人員基本都遇到過,可以先回憶或考慮這個數據表如何設計!
定義:
存在遞歸關係的數據很常見,數據常會像樹或者以層級方式組織。在樹形結構中,實例被稱爲節點(node),每個節
點有多個子節點和一個父節點,最上面的節點叫根(root)節點,它沒有父節點,最底層的沒有子節點的節點叫葉
(leaf), 中間的節點簡單地稱爲非葉(nonleaf)節點。
評論數據就是一種樹形結構數據,評論的子節點就是它的回覆。其他的樹形結構數據像職員與經理的關係,菜單等等很多;
方案:以下所有方案中暫不考慮外鍵約束,數據庫是MYSQL!
-
鄰接表
這個可能是最常見的解決方案,直接添加parent_id字段,引用同一張表中的其他回覆。表結構如下
CREATE TABLE `Comments` ( `comment_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '評論ID', `parent_id` int(11) NOT NULL DEFAULT '0' COMMENT '評論的父ID', `article_id` int(11) NOT NULL DEFAULT '0' COMMENT '文章ID', `comment` varchar(200) DEFAULT '' COMMENT '評論內容', PRIMARY KEY (`comment_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='簡化的評論表';
鄰接表總是依賴父節點,看看它的優缺點:
-
無法完成樹操作中最普通的有一項,查詢一個節點的所有後代;
- 要用一條簡單的sql檢索一個很長的回覆分支還是很困難的;
- 也可先獲取文章的所有評論,在程序的棧內存中處理整合,但數據量,訪問量都大,每次有人訪問都要做一次數據處理也不切實際;
- 增加葉子節點操作是非常方便的;
- 刪除節點會變得比較複雜:考慮數據完整性,刪除一棵子樹,不得不考慮處理其所有的後代節點;
-
上述這種方案可被叫做:‘單純的數‘ 反模式!
要合理的使用反模式:鄰接表設計的優勢在於能快速地獲取一個給定節點的直接父節點,也很容易插入新節點。如果這樣的需求就是你的應用程序的需求,那使用鄰接表就可以很好地工作!
下面再看看其他的方案:
-
路徑枚舉
路徑枚舉的設計通過將所有的祖先的信息聯合成一個字符串,並保存爲每個節點的一個屬性:
CREATE TABLE `Comments` ( `comment_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '評論ID', `path` varchar(1000) NOT NULL DEFAULT '0' COMMENT '路徑:eg: 1/2/4', `article_id` int(11) NOT NULL DEFAULT '0' COMMENT '文章ID', `comment` varchar(200) DEFAULT '' COMMENT '評論內容', PRIMARY KEY (`comment_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='簡化的評論表';
來看看該方案有沒有解決鄰接表的問題,
1. 通過比較每個節點的路徑來查詢一個節點的祖先:例如查找comment_id 爲4的所有的祖先的sql:
SELECT * from Comments AS c where '1/3/4/' like CONCAT(c.path,'%');
2. 查詢一個節點的所有後臺:例如 comment_id 爲 1 的所有後臺:
SELECT * from Comments AS c where c.path like CONCAT('1/','%');
3. 插入節點:只需一份父節點的路徑即可;comment_id是自動生成,需要先插入再修改;
該方案的缺點:數據庫不能確保路徑的格式總是正確或者路徑中的節點確實存在,需應用程序的邏輯代碼來維護,且驗證字符串的正確性的開銷很大;再者,無論將varcharde的長度設定爲多大,依舊存在長度限制,因而不能支持樹結構的無限擴展。
-
閉包表
閉包表記錄樹中所有節點間的關係,而不僅僅只有那些直接的父子關係,是一個簡單而優雅的分級存儲解決方案。
該方案不再使用Comments表來存儲樹的結構,而是將樹中任何具有祖先-後代關係的節點對都存儲在新表中,即使兩個節點不是直接的父子關係,同時,還增加一行指向節點自己,表結構如下:
CREATE TABLE `Comments` ( `comment_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '評論ID', `article_id` int(11) NOT NULL DEFAULT '0' COMMENT '文章ID', `comment` varchar(200) DEFAULT '' COMMENT '評論內容', PRIMARY KEY (`comment_id`) ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8 COMMENT='簡化的評論表';
CREATE TABLE `TreePaths` ( `ancestor` int(11) NOT NULL DEFAULT '0' COMMENT '祖先', `descendant` int(11) NOT NULL DEFAULT '0' COMMENT '後代' ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
下面看看相關操作
1. 搜索祖先:搜索評論5的祖先:
SELECT c.* from Comments as c JOIN TreePaths as t on c.`comment_id` = t.ancestor WHERE t.descendant=5;
2. 搜索後臺:搜索評論1的後代:
SELECT c.* from Comments as c JOIN TreePaths as t on c.`comment_id` = t.descendant WHERE t.ancestor=1;
3. 插入子節點:
例如評論5新增一個子節點,應首先插入一條自己到自己的關係,然後搜索TreePaths表中後代是評論5的所有節點,增加這些節點和新節點的’祖先-後代‘關係。
TreePaths表可以繼續優化:增加path_length字段表示祖先與後代的層級數等等;
-
綜述
以上列舉了三個方案,沒種設計都各有優劣,如何選擇設計依賴於應用程序中的哪種操作最需要性能上的優化:
- 鄰接表是最方面的設計,並且很多開發中都瞭解它;
- 路徑枚舉能夠很直觀地展示出祖先與後代之間的路徑,但同時由於它不能確保引用完整性,使得這個設計十分脆弱,
- 閉包表示通用的設計,它要求一個張額外的表來存儲關係,使用空間換時間的方案減少操作過程中冗餘的計算所造成的消耗。