业务逻辑封装到存储过程中的优缺点。

好，非常感谢各位，我不是认同这种做法，只是想听听大家的思路。因为有句话说“存在即合理”， 所以我想看看他合理在哪儿，不合理在哪儿。

稍微整理一下：
优点：
性能一般会有提高。
逻辑的修改可以即时发布，不需要编译和发布代码。

缺点：
不能应用面向对象的思路和设计。


－－－－－－分割线－－－－－－

对于数据库变更，这其实不能算是个问题的问题，因为不是做产品销售出去的话，如果是自己公司的ERP系统等，数据库定下来之后极少改变的。
－－－－－－分割线－－－－－－

对于重用，有一种叫代码级重用，这个无论在哪里都能做到的。 另外，既然叫存储过程，本身就是面向过程的，所以面向对象中的概念自然不能在这里应用。虽然没有继承，但是过程依然可以调用过程，这也是一种重用。
－－－－－－分割线－－－－－－
请大家继续参加讨论，谢谢！

面向过程的????存储过程
传临时表还是传游标
传回来时怎么办

看做什么样的项目，据我所知ORACLE ERP基本所有的业务逻辑都在存储过程中实现

那你有亲手做过么？做过的话谈谈体会心得啊，谢谢。

小弟做过两个项目涉及了一些存储过程，体会就是
优点就是执行速度较快
缺点就是写起来麻烦，不好调试

基本上不用

楼下继续

优点速度快，之前做的一个项目，类似股市行情，每秒实时刷新大量数据，迫不得已，写了存储过程。
缺点就是难于调试。
对于一般的项目，数据库倒是很少变动的。而且发现对于性能要求高的系统，很多时候结构的优雅要让位于运行的效率

优点：
性能一般会有提高。
逻辑的修改可以即时发布，不需要编译和发布代码。

缺点：
不能应用面向对象的思路和设计。
调试困难。
------------------------
还有么？大家请踊跃发言啊～

补充一下：
优点： 对于大数据量的复杂的逻辑，减少网络传输。
       充分利用了数据库本身的优化性能。
缺点：可移值性差。（虽然少有需要移值数据库的，不过现在我就要面对这个问题。要从sybase移到oracle，有近100个存储过程要我重写啊！）

优点：
性能一般会有提高。(对于大数据量的复杂的逻辑，减少网络传输。充分利用了数据库本身的优化性能。 )
逻辑的修改可以即时发布，不需要编译和发布代码。

缺点：
不能应用面向对象的思路和设计。
调试困难。
可移值性差。
------------------------

Welcome every body, say what you want to say, please!