SQL存储过程越多越好?
我把网站里几乎所有select都做成存储过程了,效率上应该只好不会坏吧?

------解决方案--------------------
我把网站里几乎所有select都做成存储过程了,效率上应该只好不会坏吧?
******************
传统的观念：存储过程执行一次以后被缓存，这样下次执行此存储过程就可以提高性能。
但是从sql2000开始，后台代码中的sql语句也有类似的功能了。
所以效率的提升不在于使用后台sql还是存储过程，关键在于你的select语句怎么写，数据表建了合适的索引没。
当然使用存储过程比后台sql有一个明显的好处就是，修改存储过程以后不需要重新编译代码。
------解决方案--------------------
我觉得不是越多就越好,关键在于你的SQL语句和要实现的功能.
------解决方案--------------------
应用存储过程应该有选择的来做，如果太多调试也不方便，还有不方便移植，我的做法是通常需要在数据库服务器做很多工作的情况下才应用存储过程，普通select没必要，如果条件很多的或需要临时表操作的才用存储过程。。
------解决方案--------------------
但是如果你当前系统要改在ORACLE就不太好移植了,各有各的好处吧,把它们放到恰当的位置才最重要.
------解决方案--------------------
应用存储过程应该有选择的来做，如果太多调试也不方便，还有不方便移植，我的做法是通常需要在数据库服务器做很多工作的情况下才应用存储过程，普通select没必要，如果条件很多的或需要临时表操作的才用存储过程。。


同意！
------解决方案--------------------
同意楼上的。
不过如果要考虑数据库移植问题，你也别指望用纯后台sql就能搞定，没那么简单。常见的做法是对不同的数据库分别创建不同的数据存取层。
------解决方案--------------------
存储过程和触发器都是不可移植的，也就是说当你想更换数据库时，你将不得不重写这些存储过程和触发器。所以在java项目中不提倡用存储过程。
------解决方案--------------------
存储过程执行一次后被缓存，但正如micor(愿赌服输)所说的它是不可移植的，至于是不是使用存储要根据实际情况来确定。
------解决方案--------------------
多了就成了腐臭的垃圾
------解决方案--------------------
只站在执行效率角度来考虑的话，楼主的做法是非常不错的，存储过程在执行方面比SQL快。
------解决方案--------------------
没必要一味的追求使用存储过程。
------解决方案--------------------
简单的未必见得比sql语句快
------解决方案--------------------
应该视情况而定
不一定越多越好的
------解决方案--------------------
1. 理论上存储过程比SQL语句快.
2. 存储过程安全.
3. 太多难以维护.
我使用存储过程的原则是.
1. 复杂查询.
2. 处理大量数据.


------解决方案--------------------
我做过的几个外包项目（架构师都是一流的），别说查询，就是增、删、改，都全是写在存储过程里的。这样做有三个非常大的优点：一、安全；二、效率高；三、系统越大维护起来越方便。
------解决方案--------------------
优点：
（1）请求时传送数据量小。
（2）主程序代码清晰。
缺点：
（1）数据库不易移植，如果从SQL Server改为Oracle，需要重写存储过程。
（2）存储过程维护比较麻烦，需要记住一个一个函数是干什么的。
我的异常网推荐解决方案：oracle存储过程,http://www.aiyiweb.com/oracle-develop/177537.html