java和oracle的groupby哪个更合适?

[逗泥丸的平方]

RT... 是一张交易用表... 应该会频繁修改..

主要字段有交易ID,交易对手,交易金额等..

一笔交易是一个包,多个交易ID,也可能有多个交易对手...

所以,需要使用交易对手(其中一个字段)来统计金额,但是条件是IN 一个范围的交易ID . (虽然这笔交易可能也有共同的成交编号,但是其他系统的交易中,成交编号并不是必须字段)

这样如果写sql,最简单的想法就是

SELECT xxx FROM trade WHERE 交易对手 IN (aa,bb,cc ... )  

GROUP BY 是交给数据库做好,还是java来做比较好? 或者有更合理的实现方式?

[逗泥丸的平方]

SELECT xxx FROM trade WHERE 交易ID IN (aa,bb,cc ... )   GROUP BY  交易对手

这里写错了.. 没注意到 .

[逗泥丸的平方]

引用 2 楼 zonghsh007 的回复:

交给数据库啊。数据库自带的Group By肯定是经过他本身优化的，你自己用Java去group by，一般没它效率高的

额.. 这样吗. 因为本身是一个in了,又没法给交易对手加聚集索引,所以这里不是太放心. 虽然groupby肯定在传输中数据量会比较小. 以前做过一个项目的想法主要是,数据库资源一般是有限的,所以操作尽量放到server来做.

[逗泥丸的平方]

引用 1 楼 wlwlwlwl015 的回复:

看需求~根据你的描述如果这张表的数据有频繁的修改操作还是用sql处理合适一些~ 因为即使在内存中处理~还是需要不断从DB同步数据~ SQL根据情况优化~ 通过Oracle的执行计划explain去进行实际情况下的效率测试~

首先这张表同时保存了单笔的交易和这种多笔的交易,但是关联关系在另一个系统中... 那个系统中这是两种不同的交易..而对于我这边的系统(检核系统)来说是一致的... 频繁修改倒是不至于说在同一事务中不断修改... 因为要client接到反馈才可能进行下一笔 至于说... SQL根据情况优化~ 就是现在还不太清楚这里的活跃程度.. 虽然听说应该不会太多... 理论上...... 暂时拿不到生产上的数据,也只能先做做看了.

[小灯光环]

看需求~根据你的描述如果这张表的数据有频繁的修改操作还是用sql处理合适一些~
因为即使在内存中处理~还是需要不断从DB同步数据~
SQL根据情况优化~ 通过Oracle的执行计划explain去进行实际情况下的效率测试~

[一剑侵心]

交给数据库啊。数据库自带的Group By肯定是经过他本身优化的，你自己用Java去group by，一般没它效率高的