: 寫 code 難免 : 我講一下我的解決方案 : 首先，部門應該要有部門代號 (table的pk或是entity的@Id) : 查詢時可以把部門代號當條件 我的確是有seq(就像是部門代號)， 但是我今天送進來的條件就是"名字"，整個支線每個節點的名字 : 舉個例來說，你去商店說你要HTC手機，店員會問你型號 : 不然誰曉得你要哪一隻? : 店員也可以把所有HTC手機拿出來給你選。 : 總之不可能心電感應就對了。 : 第二種是往上檢查的 JPQL : 假設 samsung 手機型號是這樣悲慘的分類 : Samsung ─ galaxy ┬ S ─ 3 : └ Tab ─ 3 : 首先要查 "3"，會查出兩個 : 所以要把父節點當作查詢條件 : select x from x where x.name=(?1) and x.parent=(?2) : ?1 就給 String : ?2 就給 Entity : 這兩種方式雖然不能說是完美解，但在邏輯上說得通。 : 有清楚的邏輯，就算要寫code，應該也不會太笨吧? : 如果真的覺得寫code很麻煩，改scheme很麻煩的話 但是這樣只能送兩層，就像我舉 Ea 的例子， 假設好死不好 Ea 跟 Df 上一層 都叫做同樣的名字， 那這樣還是會查出兩筆~ *不過我在寫入的時候已經控制好，樹狀結構不會有重複的情況， 也就是說最多最多到B那一層，名字就一定不一樣，會分開了， 但B各支線向下或許有可能會有同樣的節點名稱 : 有 framework 是可以到這種程度的 : @Query("select x from x where x.name=(?1) and x.parent=(?2)") : public MyEntity myAutoQuery(String name, MyEntity parent); : 就寫好了。 這個我在孤狗一下，感謝提供資訊<(_ _)> : 另外，程式這東西一定要有規則綁住，不然會很麻煩 : 例如："萬一我部門代號也重覆怎麼辦" : 就不要讓他重複阿，重複就代表資料有問題，要去找到為什麼會重複 : 而不是去想 "代碼重複後我要怎樣做才能只輸入代碼就只查到一筆資料" : 就像如果有人問說 : "我的電腦只要拔掉電源線就會關機，你能讓我的電腦拔掉電源線不關機嗎?" : 我們要解的是不要讓 user 腳賤一直踢到電源線， : 而不是真的讓電腦可以在無電底下運作 -- 我以為認真去做就能實現我的夢 以為寫首好歌走路就能抬起頭 以為騎摩托車旅行就能變英雄 黃玠 現在的我 失去了衝動 香格里拉 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 125.227.157.211 ※ 文章網址: http://webptt.com/m.aspx?n=bbs/java/M.1405575333.A.D5A.html 二維表是...? 其實最主要還是透過 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: 常常會很想說我要找出完美的設計，結果事實並不然， 所以就只能在幾個方案中根據系統情況來使用較佳的方案 >"< ※ 編輯: NullLife (125.227.157.211), 07/18/2014 10:43:42