※ 引述《NullLife (929rock化)》之銘言： : 其實最主要還是透過 yyc1217 板大的方法，將上面階層攤平成一個字串 : 因為表的巢狀不太深，頂多3~5層，每層名字也不會太多頂多2~6個字 : 然後我實際的情況會像是那一張表存放N多個公司的處部狀況， : 有多個根，可能處部完全重複，僅公司不同，例如: : seq | name | parent | company : 1 aa 甲 : 2 bb 1 甲 : 3 cc 2 甲 : 4 dd 1 甲 : 5 ee 4 甲 : 6 ff 5 甲 : 7 gg 甲 : 8 hh 7 甲 : 9 ii 8 甲 : 10 aa 乙 : 11 bb 10 乙 : 12 cc 11 乙 : 13 dd 10 乙 : 14 ee 11 乙 : 15 ff 14 乙 : 麻煩是在有需求下distinct，找出所有所有處部情況 : 因為這張表最早開給user自己去維護他們的分類， : 不過內部討論過後，決定不開給USER自行維護(避免太深等問題) : 由我們系統維護人員來幫客戶進行修改新增等 : 因此分類表就可以獨立出來不跟公司掛勾，變成如下表: : seq | name | parent | parentStratum : 1 aa : 2 bb 1 aa : 3 cc 2 aa/bb : 4 dd 1 aa : 5 ee 4 aa/dd : 6 ff 5 aa/dd/ee : 7 gg : 8 hh 7 gg : 9 ii 8 gg/hh : 如此一來就不會有過多重複的 parentStratum : 也不用全查資料後下distinct找出所有分類情況， : 因為獨立出來的表就直接是結果了， : 然後在公司的表上面JoinTable來記該公司擁有哪些分類節點 : 當然每家公司的分類情況必定存在分類表裡， : 如果沒有的話，就是新增某個支線之後，將他LINK給該公司 : 所以想查Aa/Ba/Ca/Db...的時候，只要將分類串起來用like去找就好， : 因為分類表資料已經大幅縮減了，因此速度上會較之前設計的表快， : 然後公司若要調整分類結構，也不會像之前設計的表，非常難維護， : 只要變更LIKE表的結構，及調整完成。 : 以上就是我們最後決定出來的模式，感謝各位。 : PS: : 常常會很想說我要找出完美的設計，結果事實並不然， : 所以就只能在幾個方案中根據系統情況來使用較佳的方案 >"< 你的做法很ok 也就是我們常說的denormalize的做法.. 另外一個是我認為也可行也是normalize的做法 但是需要資料庫的支援.. 就是recursive query http://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL 第一步還一樣先找出所有符合的資料 在你這邊就是部門名稱 　 第二部是針對第一步的每筆資料找出Path或是Root 可以用recusive的方式 我以MSSQL Server為例子 with temp(seq, parent) as ( (select seq, parent from Department where seq = :target_group) union all ( select D.seq, D.parent from Department as D, temp where temp.parent = D.seq ) ) select * from temp where seq = :root_group with裡面會做recursive 第一個subquery是第一筆資料 第二個subquery是recusive去做直到到boundary 當然第一步如果有找到3比結果 就要3+1次query 但是可以方便你快速的追到你想要的root 或是你要做denormalize的地方 也可以用這個方法來建立出你的path 是有點複雜，就僅供參考 XD --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.46.230 ※ 文章網址: http://webptt.com/m.aspx?n=bbs/java/M.1405655110.A.F86.html