類似的情況在實務上有遇過很多次。也用過不少方法去解決， 現簡單羅列出來，希望能給大家一點方向去決定合用的情況。 首先從persistence 層面出發，實際用過的方法有兩種: A) 最直覺的方法：每個 node 存 parent 的 ID （就是之前文 章用的方法） B) 每個 node 存的是 "左右" 兩數值, 類似: http://www.sitepoint.com/hierarchical-data-database-2/ A) 最能對應 OOP，本身的資料就是差不多直接對映 hiererchy 的結構 e.g. class Node { Node parent; List<Node> children; } 實際轉換成 object 來操作的話，A 會比較容易和直覺 B) 對於一般的 DB (何謂非一般後面再解釋）來說，能輕易就 能用 SQL 取得某node 底下的 subtree, 或某 node 的 parents， 單純用 SQL 作 insert/delete 等也蠻簡單。但轉換成 object 操作 的話就不太能直接做到 （至少不能簡單利用 ORM 的內置 insert/update 功能） ----------------------------------------------------------------------- 雖然 A 方法對映成 object 很直覺，但還是有一個大問題（就是原問 者提到的）: 假設要找某 node 的 subtree 或 parents，不容易直接一句 query 就做到 解決方案有以下: 1) 依靠實際 object 的 navigation，找出你的要 node，然後要找 subtree 或 parents 就輕易很多了。 要做到這效果，方法有以下： i) 單純從 DB retrieve 該 node, 然後依靠各 JPA 實作提供的 lazy fetching, 當你 navigate 某 node 的 parent / children，當時才 自動去 DB 取得。 這是我唯一一個不會建議的方法（我也沒有實際做過），因為會不必要 地大量 acess DB (有多少個 node 就會跑多少句 SQL)。 ii) 把整棵 tree structure 一次讀入，然後在 memory 建立整個 tree structure。 一般來說，現在的 DBMS 和網路，跑一句簡單但結果行數大的 QUERY， 比跑一句複雜但結果量比較小的QUERY，前者會有效率得多 （除非真的 是上十萬或百萬行），只要留心一下 JDBC 的 FETCH SIZE 就好了。 2) Query 取得相關的資料。 在 B) 裡面不是說 A) 的結構不宜 query 嗎？對的，不過現在不少 DBMS 都 有提供 hierarchical query 的功能，比如 oracle: http://docs.oracle.com/cd/B19306_01/server.102/b14200/queries003.htm 靠這種做法，可以有單純的 DB schema，也可以一句 query 就找到你想要的 subtree etc. 最大的問題是這類 query 是廠商特有的語法，你不可能用 JPQL 或 HQL 之類 寫出來。要是寫 native query 不是大問題的話，這方法也可以考慮。 找到需要的 subtree, 再結合 object navigation，就可以很有效地做到需 要的功能。 個人的建議是 A1i > A2 > B > A1ii A1i 做起來單純，需要的特別知識也少，只要你的 tree strucuture 不是 超巨大(數萬 node 以上），一句 query 拿回來然後讓 JPA 幫你建構整 個 tree structure 是最直接又簡單的做法 B 則是當你的設計主要依靠 SQL 會比較有用 （你的情況看來並非如此） 一點經驗分享，希望有用 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.19.42.87 ※ 文章網址: http://webptt.com/m.aspx?n=bbs/java/M.1405741506.A.16C.html ※ 編輯: adrianshum (223.19.42.87), 07/19/2014 11:45:57 ※ 編輯: adrianshum (223.19.42.87), 07/19/2014 11:47:09