: 写 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/cn.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