以下比较不太全面，纯粹是个人的理解。可能是针对前一篇文章的补充与说明
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服务器更新应用来满足需求的变化。
先写这些吧，写东西太耗时间了。还是等压力测试的数据出来再做一些分析吧。