什么时候用存储过程合适

当一个事务涉及到多个SQL语句时或者涉及到对多个表的操作时就要考虑用存储过程；当在一个事务的完成需要很复杂的商业逻辑时（比如，对多个数据的操作，对多个状态的判断更改等）要考虑；还有就是比较复杂的统计和汇总也要考虑，但是过多的使用存储过程会降低系统的移植性。

存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL 语句集，存储在数据库中经过第一次编译后再次调用不需要再次编译，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。存储过程是数据库中的一个重要对象，任何一个设计良好的数据库应用程序都应该用到存储过程。

当一个事务涉及到多个SQL语句时或者涉及到对多个表的操作时就要考虑用存储过程；当在一个事务的完成需要很复杂的商业逻辑时（比如，对多个数据的操作，对多个状态的判断更改等）要考虑；还有就是比较复杂的统计和汇总也要考虑，但是过多的使用存储过程会降低系统的移植性。

 

为了系统的控制方便，例如当系统进行调整时，这是只需要将后台存储过程进行更改，而不需要更改客户端程序。也无需重新安装客户端应用程序。

存储过程不仅仅适用于大型项目，对于中小型项目，使用存储过程也是非常有必要的。其威力和优势主要体现在：
  1.存储过程只在创造时进行编译，以后每次执行存储过程都不需再重新编译，而一般 SQL 语句每执行一次就编译一次,所以使用存储过程可提高数据库执行速度。
  2.当对数据库进行复杂操作时(如对多个表进行 Update,Insert,Query,Delete 时），可将此复杂操作用存储过程封装起来与数据库提供的事务处理结合一起使用。这些操作，如果用程序来完成，就变成了一条条的 SQL 语句，可能要多次连接数据库。而换成存储，只需要连接一次数据库就可以了。
  3.存储过程可以重复使用,可减少数据库开发人员的工作量。
  4.安全性高,可设定只有某此用户才具有对指定存储过程的使用权。

优点：
1.速度快。尤其对于较为复杂的逻辑，减少了网络流量之间的消耗
我有的过程和函数达到了几百行，一个微型编译器，相信用程序就更麻烦了。
2.写程序简单，采用存储过程调用类，调用任何存储过程都只要1-2行代码。
(我不知道别人怎么调用，我是深受其益）
3.升级、维护方便
4.调试其实也并不麻烦，可以用查询分析器
5.如果把所有的数据逻辑都放在存储过程中，那么asp.net只需要负责界面的显示阿什么的，出错的可能性最大就是在存储过程。我碰到的就一般是这种情况。

缺点：
1.可移植性差，我一直采用sql server开发，可是如果想卖自己的东西，发现自己简直就是在帮ms卖东西，呵呵。想换成mysql，确实移植麻烦。
2.采用存储过程调用类，需要进行两次调用操作，一次是从sql server中取到过程的参数信息，并且建立参数；第二次才是调用这个过程。多了一次消耗。
不过这个缺点可以在项目开发完成，过程参数完全确定之后，把所有过程参数信息倒入到一个xml文件中来提高性能。

 

当一个业务同时对多个表进行处理的时候采用存储过程比较合适。

 

1. 使用存储过程在一般情况下会提高性能，因为数据库优化了存储过程的数据访问计划并应用缓存方便以后的查询；
2. 
   
3. 存储过程单独保护存在于数据库中。客户端可以获取权限执行存储过程,而不需要对底层的具体表设置其他的访问权限；
4. 
   
5. 存储过程会使得维护起来更加方便，因为通常修改一个存储过程要比在一个已经发布的组件中修改SQL语句更加方便；
6. 
   
7. 存储过程给底层数据格式增添了额外的抽象层。使得使用存储过程的客户端对存储过程的实现细节以及对底层数据格式是隔离独立的；
8. 
   
9. 存储过程能够缓解网络带宽，因为可以批量执行SQL语句而不是从客户端发送超负载的请求。

复杂的数据处理用存储过程，如有些报表处理

多条件多表联合查询,并做分页处理

( 转载)

------------------------------------------------------------------------------------------------------------------------

　　说白了，就是业务逻辑部署在哪里的问题。部署在数据库，程序里当然只有数行的调用代码，当然是这种做法有一定好处，如减少了客户端的运算压力等，但好坏是相对的，就拿这点来说，客户端压力少了，服务端压力就会变大，好

与非好不是一个人说了算的，要考虑技术和物理支撑多方面因素，当然我认为主要是技术上的问题占主导，偏向数据库技术的人一般喜欢存储过程，这没绝对的对错，但别太过偏执自己的观点。然而对于基于.NET开发的程序员，程序代码

是主，数据库是次，次只是附属，而不是必需品，众多额.NET开发人员还是应该把业务逻辑写在.NET代码上，以便业务逻辑在不断更替的技术中重用。反之，项目经理今天用关系型数据库来支撑项目，明天也可以用NoSQL,甚至是

XML，TXT之流作为持久化介质。当然更换持久化介质的频率不会很频繁，但如果真要算一算生命周期，也不会很长，除非你的工作生涯是和公司绑定死，并且公司是不会普及新技术的会一直用关系型数据库到永远。我想没人会这么傻

吧？就算你愿意，公司也不一定坚持到你退休。看待这个问题要放长双眼，而不是墨守成规，沾沾自喜。

------------------------------------------------------------------------------------------------------------------------------------

　　团队的技术背景问题。。。存储过程效率上的优势还是有的

------------------------------------------------------------------------------------------------------------------------------------

FROM: http://www.360doc.com/content/13/0513/17/3776353_285164496.shtml#