关于将应用逻辑放在存储过程(PL/SQL)或应用层的选择

当今社会强调和谐，我们程序员也不能落后，IT行业经常存在这种和那种语言，这种方法与那种方法之争，其实我觉得这是没必要的，存在既有道理，任何事物都有它的适用的地方，没有最好的，只有最合适的，今天看了篇关于应用逻辑放在存储过程或应用层的讨论，总结了一下其中的观点,欢迎大家拍砖

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

应用层:
1.一般性的业务逻辑应该放在中间层，这对软件以后的技术扩展有很多好处，像网格技术，就是基于中间件技术的。
2、性能扩展性问题：随着系统访问量的增长，系统必须进行不断地升级扩展，特别对于大型系统而言，更重要的是性能可扩展性而不是局部的性能。J2EE等多层结构要解决的也是这方面的问题。处理逻辑如果全部放在存储过程里，所有的处理都在数据库服务器上进行，消耗的就是数据库服务器的CPU资源，大家知道数据库服务器由于需要较高的可靠性，通常选用的都是价格昂贵的服务器，对数据库服务器升级通常都花费很大。如果把处理逻辑放在中间层服务器上进行，中间层服务器一般都是小型的机器，价格便宜，