1 最常用來儲存樹的結構,儲存上級節點id 屬於一種反模式
2 使用鄰接表來維護樹
使用這種反模式來維護樹，一些操作是非常方便，比如增加葉子節點，修改乙個節點和一顆子樹的位置，然而從一棵樹中刪除乙個節點會變得比較複雜，比如刪除一顆子樹，你不得不執行多次查詢來找到所有的後代節點，然後逐個從最低級別開始刪除這些節點，以滿足外來鍵完整性，也可以使用 on delete cascade修飾符的外來鍵來自動完成這些操作，使用鄰接表時需要多步操作才能完成的查詢例子，不得不寫很多**，而資料庫涉及本身就可以做到簡單和高效。
3 解決方法
1 路徑列舉
2 巢狀集
3 閉包
以空間換時間，將存在任何具有 祖先-後代的關係存在一張表（treepaths）中，同時還增加一行節點指向自己。
查詢樹select c.* from comments c
join treepaths t on c.comment_id=t.descendant
where t.ancestor=1
查詢父節點
select t.ancestor,t.descendant from treepaths as t
where t.descendant =5
新增新節點
SQL反模式總結
1.亂穿馬路 現象 在乙個表鍵中存放多個值，用，類似的符號隔開 問題 這會讓查詢.插入和刪除的效率變得非常低 解決方案 不要在乙個表鍵中存放多個值，將所有原本在乙個表鍵中的值存放到一張單獨的表，在新錶中建立兩個屬性，乙個與原表的主鍵建立外來鍵關係，乙個標明值。例子見表 產品id 經銷商 1 張三 1...
《SQL反模式》讀後感
年前買了這本書，在家沒事看看，二百多頁，沒幾天就看完了。印象最深的就是這句 所謂專家,就是在乙個很小的領域裡把所有錯誤都犯過了的人 可以看出來作者自己確實犯了很多很多錯誤，所以書裡談論的問題是實際應用中遇到的真問題，只這一點，我覺得買這本書值了。其他優點就不說了，沒那個談一件事之前先來一大段吹捧的習...
SQL反模式筆記18 使用 查詢
目標 減少輸入 反模式 使用 缺點1 傳輸的資料量大。解決方案 明確列出列名 這一章內容太簡單了，好像沒啥可說的。我想起用ibatis的時候遇到的乙個問題 最初的sql都是自動生成的，比如根據id update某個表，輸入引數是這個表對應的乙個entity，包含了這個表幾乎所有的字段。這樣使用的時候...