关于存储过程的优缺点，大家发言，来的都有分，下午下班之前结贴
1.用存储过程编写复杂的业务逻辑，复杂的多表查询等等，
2.就是不用存储过程，所有的t-sql 都写在类里面，然后用ado.net连接数据库，各种查询出N个DataTable 然后处理

大家说说啊，领导让我写一篇东西出来，我在网上也收集了不少，大多数都是抄来抄去的，只是想听听各位大牛的想法，谢谢



------解决方案--------------------
我觉得应该
3.使用存储过程，但是不要再存储过程实现业务逻辑，只是在存储过程实现一些数据关联的逻辑。

------解决方案--------------------
我觉得速度，肯定是速度。。。。
------解决方案--------------------
程序中可以实现事务的

复杂业务逻辑放在存储过程看起来是最简单的方法，但是以后维护会很麻烦，特别是业务逻辑可能涉及修改的部分
------解决方案--------------------
一次编译多次受惠
------解决方案--------------------

探讨

程序中可以实现事务的

复杂业务逻辑放在存储过程看起来是最简单的方法，但是以后维护会很麻烦，特别是业务逻辑可能涉及修改的部分

------解决方案--------------------
上面说过的我就不说了，补充一下 ，在网络环境中，明文容易被破译、攻击等等。然后也容易造成SQL 注入。存储过程能很好处理这些问题，并且源代码超过8K，内存就要动用到系统内存来处理了。而客户端传过来，如果仅仅是一个存储过程名及参数，那么肯定不会超过8K。从整个系统的角度看，性能会有所提升。
------解决方案--------------------
所有的业务逻辑都写到存储过程了里面只会给你带来无尽的痛苦。后期的维护是很痛苦的。

然而存储过程有它自身的优点，除了只编译一次以外，实现事务相对比较简单。这个就要靠你自己来取舍了。
------解决方案--------------------
我觉得当要执行很多个sql语句时，使用存储过程可以加快运行速度
------解决方案--------------------
优点:
#1. 存储过程的效率会好些
#2. 业务逻辑放在存储过程中，一定程度上做到了代码与业务分离。建议一些Check的逻辑放在代码中，实际操作数据的逻辑放在存储过程中。

缺点：
#1. SQL为面向过程的，调试和修改都比较麻烦些。

------解决方案--------------------
存储过程 不能写的太复杂；
功能受限，与数据操作有关的使用。
交互性和维护性不好。
------解决方案--------------------
存储过程
优点是高效、集中
缺点是调试困难、集中