存储过程:
1.编译后生成中间代码，该代码的执行效率远比客户端数据库访问快,但是大多数高级的数据库系统都有statementcache的，所以编译sql的花费没什么影响。但是执行存储过程要比直接执行sql花费更多（检查权限等），所以对于很简单的sql，存储过程没有什么优势。
2.使用的是服务器端游标，而客户端程序使用的是客户端游标，速度快
3.不需要象 J2EE 的程序那样要部署，适当的时候只需在后台更新，便于调试与维护
4.占用网络流量较少，如果在存储过程中没有多次数据交互，那么实际上网络传输量和直接sql是一样的。

应用层:
1.一般性的业务逻辑应该放在中间层，这对软件以后的技术扩展有很多好处，像网格技术，就是基于中间件技术的。
2、性能扩展性问题：随着系统访问量的增长，系统必须进行不断地升级扩展，特别对于大型系统而言，更重要的是性能可扩展性而不是局部的性能。J2EE等多层结构要解决的也是这方面的问题。处理逻辑如果全部放在存储过程里，所有的处理都在数据库服务器上进行，消耗的就是数据库服务器的CPU资源，大家知道数据库服务器由于需要较高的可靠性，通常选用的都是价格昂贵的服务器，对数据库服务器升级通常都花费很大。如果把处理逻辑放在中间层服务器上进行，中间层服务器一般都是小型的机器，价格便宜，而且中间层服务器的CPU通常主频比数据库服务器的速度还快（比如现在8CPU的数据库服务器主频只有800M，而双CPU的刀片式服务器CPU主频已经到2.8G了），而且对于多层架构，支持中间层服务器可以增加多台机器进行负载均衡，用中间层服务器即价格便宜，扩展空间也更大。
3、开发问题：存储过程还是过程型语言，其重用性比不上JAVA等面向对象语言开发。用JAVA开发的中间层服务可服用性更好（当然，前提是你采用面向对象设计）
4. 实际上这个只是要将访问数据库的接口统一，是用存储过程，还是EJB，没太大关系，也就是说，在三层结构中，单独设计出一个数据访问层，同样能实现这个目标。

总结：
1.存储过程是基于计算密集型的业务逻辑。如果是基于操作密集型的就不要用存储过程了
2.所有数据访问在应用层封装为数据访问层，在那里，如果SQL简单的话，直接用SQL；如果SQL复杂，或者数据交互多且中间数据最后不会用到，使用存储过程
3.（对于核心的算法，不变的东西放在前台程序中。对于容易改变的字典数据，接口逻辑和配置信息，可以放在后台用存储过程来完成。最大好处，也是最终目的是：源程序不改，只改后台存储过程就可以潇洒应付客户需求的改变。）这个不知道对不对

 

 

触发器一般是用于在一个表的数据更新后，触发相关表实现联动更改，这样做有一个好处就是在进行数据更新时，只要更新一处数据，其他业务逻辑需要修改的地方就能全部交由数据库定义的触发器在数据库层面修改其他表的数据。

这些业务，比如说用户登录动作，在用户登录后，我们只要更新最后登录时间，同时通过触发器，来把用户的信息放到在线用户表里，另外也可以定义触发器在消息表里生成一些数据来推送给用户等等。

不过以我以往的经验，我建议最好不要使用触发器，可以使用队列来实现类似的功能，主要原因：

1.建立了触发器后，各表间就形成了一种耦合关系，当数据量大了以后，想做数据拆分、数据库变更、数据库存储优化等等，都非常困难了，有的甚至动不了，比如我以前经历过的一个系统，开始使用的是sqlserver数据库，上面自定义了一些触发器，不过后来数据量大了，想使用mysql来分离一些数据，但系统又要一直保持在线可用状态，想整改优化系统的存储，非常痛苦！

2.在数据库的使用原则上，我建议，最好只使用数据的存储跟查询这些最基本的功能，尽量减少数据库的逻辑运算，这样才能最大程度的发挥数据库性能，也更有利于系统的性能扩展，减低系统耦合性等。