业务逻辑层与存储过程优缺点对比

 

一,存储过程

优点:

1,减少网络带宽,按理论存储过程会提高性能.

2,无需重新编译,更改后即可运行,无需重新编译代码

3,由专门的dba写的sql语句更高效

4,安全性,(在传输用户名密码时,可防止注入等情况)

 

缺点:

1,依赖于数据库厂商,难以移植(当一个小系统发展到大系统时,对数据库的要求也会发生改变)

2,业务逻辑大的时候,封装性不够,难调试难以维护

3,复杂的应用用存储过程来实现，就把业务处理的负担压在数据库服务器上了。没有办法通过中间层来灵活分担负载和压力.均衡负载等

 

结:

存储过程用于进行一些简单的业务逻辑以及数据传送会更好维护,但是在复杂应用时,应交于中间层服务器处理.所以合适的时候用着合理的操作.

缺点，不灵活，难于维护

优点，有些复杂的处理逻辑，如果没有良好的在编程语言上的支持将非常难于实现及维护，这时可借助于存储过程更简明

缺点:

1,依赖于数据库厂商,难以移植(当一个小系统发展到大系统时,对数据库的要求也会发生改变)

2,业务逻辑大的时候,封装性不够,难调试难以维护

3,复杂的应用用存储过程来实现，就把业务处理的负担压在数据库服务器上了。没有办法通过中间层来灵活分担负载和压力.均衡负载等

------------------
1,谁没事去移值业务系统的数据库？
2,经常有人说存储过程不好调试，我不明白这么说的人有没有用过存储过程。
3,几百万买的数据库服务器，不好好利用，可惜了得。我不能买个Oracle当Mysql使。

1，谁说不会移，，当你一个系统由大到小时，难道不会移植吗？
2，难以维护这是肯定的，，数据库顶多算个结构性语言，相对于面向对象的语言，在封装性，易读性能都差太多了。。

银行，保险，电信这些行业的后台主要复杂逻辑基本上都是由存储过程来实现的。
反而是一些做简单CRUD的人，经常性的来BS存储过程。很奇怪的事情。

跑个报表用web容器实现。。。？
这个我大概很难想象。

性能瓶颈在于io操作和网络传输。。

没做过大系统的话嘛；

不过确实，存储过程可读性是略差些，调试起来也没java方便，但是直接部署在数据库服务器上运行，省掉了很多开销。

这类应用性能瓶颈就是在数据库上，web再集群也意义不大。

如果是类似淘宝这种查询请求多，倒是搞个缓存的层次意义大。电信金融类的，特别是数据汇集的需求，存储过程还是有不可替代的优势，毕竟数据库很难群集