※ 引述《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