维护过两个二次开发的项目，一直被一个问题疑惑着，为什么数据库这样设计，但是自己也想不到其他的方法，问题如下：
数据库中有两张表 ，一张为主表 ，这里命名为task；
另一张表为附表，这里命名为 detailTask； 主表和附表是一对多关系；
在detailTask中有taskId，对应主表的taskId; 通过taskId可以查询附表中主表ID的任务；
这里就有一个疑问：如何确定主表中的任务完成？ 主表有一个finishState , 附表中也有一个类似的任务完成状态标识，比如detailState;
当程序完成一个任务会将附表中的detailState 改为 已完成 状态为2 ，那么我们如何确定主表任务是否完成呢？
之前的解决方案有两种：
1.在每次改附表中的任务状态的时候，将主表的任务状态改为2，已完成； 这样最后一条附表任务完成，主表的任务就会是已完成了；
2.在主表中增加一个任务完成量，总任务量，每当附表任务完成一个，就将该数字（任务完成量）+1，当主表中的需求量和任务完成量一致，说明主表任务已完成；
对这两种方式都比较失望，第一种效率极低，频繁更改数据库； 然后后台还无法进行批量更新操作，因为需要一条一条的修改数据；（由于小任务需要分发，所以将小任务都存到了本地数据库，然后从本地数据库存到了mq中，然后各程序从mq中获取任务，取到任务完成后，会给mq一个反馈，也会修改本地数据库，也就是最后是mq中的小任务状态变化，然后定时器会更新小任务到真正的服务器中 当时这样的思路是为了减少数据库访问，但是最后在更新数据到服务器上，经常容易出现JTA事务错误,也因为最后更新到服务器过程中，没更新一条小任务，都会将大任务状态更新一遍）
第二种方式也会导致一个问题，每个月总有那么几条完成量不等于任务需求量；不定时会出现错误数据；比如完成量比任务总量少一条之类的情况；
这里希望各位能提供一些思路，比较想解决这个疑惑？推翻这种设计也未尝不可；
------解决思路----------------------
数据库表设计没啥问题。
子任务结束时需要判断是否所有子任务都已完成，都完成了才更新主表。
你这个业务压力多大啊，没啥复杂操作数据库怎么会顶不住。
你怎么得出数据库压力大的结论的。
JTA出错不一定是压力大造成的，需要仔细分析出错原因。
------解决思路----------------------
主表需要三个字段，一个finish标志， 子任务数量， 子任务完成数量
每当完成一个子任务的时候，修改 子任务完成数量加一，当子任务完成数量等于 子任务数量，的时候，设置主表finish标志为完成状态。。
当然，如果你的修改比较频繁，为了避免读写锁定等问题， 可以把这三个字段分离到 另外一个表。。。这个表通过外键与主表关联。。。
这样，你的主表就几乎没有修改操作了。。。
查询的时候关联查询就是了。
------解决思路----------------------
主表不设完成标志位, 直接用语句判断#taskId对应的task是否完成
select count(id) from detailTask dt where dt.detailState <> 2 and dt.taskId = #taskId;