以下比较不太全面，纯粹是个人的理解。可能是针对前一篇文章的补充与说明

1、批量数据的处理比较

业务逻辑：单位A部门划转到B部门，业务规则是把A部门的100人的关联单位改为B部门，同时在人员岗位变化子表里增加一条变动记录。

业务实现：

1）存储过程实现（SP实现)（两个SQL语句）

insert into 岗位变化子表（变化前部门、变化前岗位、变化后部门、变化后岗位、生效时间、操作人、操作时间） select A,岗位,B,岗位,sysdate,当前登录用户,sysdate from 员工表 where 部门ID=A；--完成插入100条子表的数据

update 员工表 set 部门ID=B where 部门ID=A; --更新员工的部门关联

commit; --最后提交，SP本身就开启了事务机制，所以可以放心操作。

2）业务类实现1（符合面向对象的原则）

获得A部门员工对象，一般是100个员工对象的Collection，即生成的SQL语句是把所有的员工表的字段都查询出来，然后循环进行员工对象属性的变更与保存、子对象的创建与保存等业务。

3）业务类实现2（有点不太符合面向对象的原则，但效率肯定比前面一种高）

按SP方式执行SQL语句。当然要注意开启事务处理，否则可能会产生垃圾数据哟。

当然可能还有除了这三种之外的实现方式，但这三种应该是最常见的了。其它的内容这里就不展开说了。希望非专业人士可以看明白。专业人士可以自行计算一下数据库连接的次数及需要传输的数据量。

需求变更：增加操作IP的记录

所有都要做的事情：增加【岗位变化子表】数据表字段：操作IP

1）SP调整

增加参数IP，修改第一条insert语句即可。

关联修改：调用存储过程方法重新调整。重新编译发布

2）业务实现1

修改岗位变化子表的实体类。（一般是重新生成即可）

修改业务逻辑类

重新编译发布

3）业务实现2

修改岗位变化子表的实体类。（一般是重新生成即可）

修改SQL语句

重新编译发布

2、数据统计类

业务逻辑：定时（每小时或每天）更新用户排行榜（如积分排行榜），假设用户积分数据8千万条数据。

业务实现：SP的方式

创建一个Job队列执行设定的存储过程，把统计的结果存到积分排行榜的数据表里。

适应需求变化：统计的规则可能经常变化，特别是积分系统的调整也是非常频繁的（可能一周就会有一次，特别是项目上线前期），存储过程可以很快的修改测试与部署。不需要指定专门的时间去停止所有的Web服务器更新应用来满足需求的变化。

先写这些吧，写东西太耗时间了。还是等压力测试的数据出来再做一些分析吧。