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

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

存储过程:
1.编译后生成中间代码,该代码的执行效率远比客户端数据库访问快,但是大多数高级的数据库系统都有statement cache的,所以编译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.(对于核心的算法,不变的东西放在前台程序中。对于容易改变的字典数据,接口逻辑和配置信息,可以放在后台用存储过程来完成。最大好处,也是最终目的是:源程序不改,只改后台存储过程就可以潇洒应付客户需求的改变。)这个不知道对不对


帖子地址:http://www.apub.org/doc/2006/03/11/09/36/51/13012.html 

你可能感兴趣的:(数据结构,sql,应用服务器,中间件,网络应用)