为什么要用存储过程

几个去 IBM 面试的兄弟回来抱怨：去了好几个不同的 IBM 项目组，几乎每个面试官问到数据库的时候都要问用没用过存储过程，烦人不？大家去面的程序员，又不是 DBA，以前的项目都没有用到存储，不照样运行的好好的？
存储过程真的那么重要吗，它到底有什么好处呢？
笔者认为，存储过程说白了就是一堆 SQL 的合并。中间加了点逻辑控制。
但是存储过程处理比较复杂的业务时比较实用。比如说，一个复杂的数据操作。如果你在前台处理的话。可能会涉及到多次数据库连接。但如果你用存储过程的话。就只有一次。从响应时间上来说有优势。也就是说存储过程可以给我们带来运行效率提高的好处。另外，程序容易出现 BUG 不稳定，而存储过程，只要数据库不出现问题，基本上是不会出现什么问题的。也就是说从安全上讲，使用了存储过程的系统更加稳定。
数据量小的，或者和钱没关系的项目不用存储过程也可以正常运作。mysql 的存储过程还有待实际测试。如果是正式项目，建议你用 sql server 或 oracle 的存储过程。数据与数据之间打交道的话，过程会比程序来的快的多。面试官问有没有用存储，实际上就是想知道前来面试的程序员到底做过数据量大的项目没。如果是培训出来的，或者小项目小公司出来的，对存储肯定接触的少了。
所以，要想进大公司，没有丰富存储过程经验，是不行的。
那么什么时候才可以用存储？对于数据量不是很大以及业务处理不是很复杂的小项目就无需要了么？错。存储过程不仅仅适用于大型项目，对于中小型项目，使用存储过程也是非常有必要的。其威力和优势主要体现在： 1.存储过程只在创造时进行编译，以后每次执行存储过程都不需再重新编译，而一般 SQL 语句每执行一次就编译一次,所以使用存储过程可提高数据库执行速度。 2.当对数据库进行复杂操作时(如对多个表进行 Update,Insert,Query,Delete 时），可将此复杂操作用存储过程封装起来与数据库提供的事务处理结合一起使用。这些操作，如果用程序来完成，就变成了一条条的 SQL 语句，可能要多次连接数据库。而换成存储，只需要连接一次数据库就可以了。 3.存储过程可以重复使用,可减少数据库开发人员的工作量。 4.安全性高,可设定只有某此用户才具有对指定存储过程的使用权。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/defonds/archive/2009/07/15/4349922.aspx

存储过程的使用，好像一直是一个争论。 我不倾向于尽可能使用存储过程，是这么认为的： 1. 运行速度： 大多数高级的数据库系统都有statement cache的，所以编译sql的花费没什么影响。但是执行存储过程要比直接执行sql花费更多（检查权限等），所以对于很简单的sql，存储过程没有什么优势。 2. 网络负荷：如果在存储过程中没有多次数据交互，那么实际上网络传输量和直接sql是一样的。 3. 团队开发：很遗憾，比起成熟的IDE，没有什么很好存储过程的IDE工具来支持，也就是说，这些必须手工完成。 4. 安全机制：对于传统的C/S结构，连接数据库的用户可以不同，所以安全机制有用；但是在web的三层架构中，数据库用户不是给用户用的，所以基本上，只有一个用户，拥有所有权限（最多还有一个开发用户）。这个时候，安全机制有点多余。 5. 用户满意：实际上这个只是要将访问数据库的接口统一，是用存储过程，还是EJB，没太大关系，也就是说，在三层结构中，单独设计出一个数据访问层，同样能实现这个目标。 6. 开发调试：一样由于IDE的问题，存储过程的开发调试要比一般程序困难（老版本DB2还只能用C写存储过程，更是一个灾难）。 7. 移植性：算了，这个不用提，反正一般的应用总是绑定某个数据库的，不然就无法靠优化数据库访问来提高性能了。 8. 维护性：的确，存储过程有些时候比程序容易维护，这是因为可以实时更新DB端的存储过程，但是在3层结构下，更新server端的数据访问层一样能实现这个目标，可惜现在很多平台不支持实时更新而已。 从上面可知道，存储过程的使用不能有死规定（全用，或全不用），以前Terminal - Server, Client-DB的方式已经过时了，存储过程很多优势已经不明显。 现在，我认为的原则是：所有数据访问在应用层封装为数据访问层，在那里，如果SQL简单的话，直接用SQL；如果SQL复杂，或者数据交互多且中间数据最后不会用到，使用存储过程。其他凭经验吧。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zy1691/archive/2009/01/09/3742780.aspx

存储过程是由一些SQL语句和控制语句组成的被封装起来的过程，它驻留在数据库中，可以被客户应用程序调用，也可以从另一个过程或触发器调用。它的参数可以被传递和返回。与应用程序中的函数过程类似，存储过程可以通过名字来调用，而且它们同样有输入参数和输出参数。 　　根据返回值类型的不同，我们可以将存储过程分为三类：返回记录集的存储过程，返回数值的存储过程（也可以称为标量存储过程），以及行为存储过程。顾名思义，返回记录集的存储过程的执行结果是一个记录集，典型的例子是从数据库中检索出符合某一个或几个条件的记录；返回数值的存储过程执行完以后返回一个值，例如在数据库中执行一个有返回值的函数或命令；最后，行为存储过程仅仅是用来实现数据库的某个功能，而没有返回值，例如在数据库中的更新和删除操作。 　　使用存储过程的好处 　　相对于直接使用SQL语句，在应用程序中直接调用存储过程有以下好处： 　　(1)减少网络通信量。调用一个行数不多的存储过程与直接调用SQL语句的网络通信量可能不会有很大的差别，可是如果存储过程包含上百行SQL语句，那么其性能绝对比一条一条的调用SQL语句要高得多。 　　(2)执行速度更快。有两个原因：首先，在存储过程创建的时候，数据库已经对其进行了一次解析和优化。其次，存储过程一旦执行，在内存中就会保留一份这个存储过程，这样下次再执行同样的存储过程时，可以从内存中直接调用。 　　(3)更强的适应性：由于存储过程对数据库的访问是通过存储过程来进行的，因此数据库开发人员可以在不改动存储过程接口的情况下对数据库进行任何改动，而这些改动不会对应用程序造成影响。 　　(4) 布式工作：应用程序和数据库的编码工作可以分别独立进行，而不会相互压制。 优点： 1.由于应用程序随着时间推移会不断更改，增删功能，T－SQL过程代码会变得更复杂，StoredProcedure为封装此代码提供了一个替换位置。 2.执行计划（存储过程在首次运行时将被编译，这将产生一个执行计划－－ 实际上是 Microsoft SQL Server为在存储过程中获取由 T-SQL 指定的结果而必须采取的步骤的记录。）缓存改善性能。 ........但sql server新版本，执行计划已针对所有 T-SQL 批处理进行了缓存，而不管它们是否在存储过程中，所以没比较优势了。 3.存储过程可以用于降低网络流量，存储过程代码直接存储于数据库中，所以不会产生大量T-sql语句的代码流量。 4.使用存储过程使您能够增强对执行计划的重复使用，由此可以通过使用远程过程调用 (RPC) 处理服务器上的存储过程而提高性能。RPC 封装参数和调用服务器端过程的方式使引擎能够轻松地找到匹配的执行计划，并只需插入更新的参数值。 5.可维护性高，更新存储过程通常比更改、测试以及重新部署程序集需要较少的时间和精力。 6.代码精简一致，一个存储过程可以用于应用程序代码的不同位置。 7.更好的版本控制，通过使用 Microsoft Visual SourceSafe 或某个其他源代码控制工具，您可以轻松地恢复到或引用旧版本的存储过程。 8.增强安全性： a、通过向用户授予对存储过程（而不是基于表）的访问权限，它们可以提供对特定数据的访问； b、提高代码安全，防止 SQL注入（但未彻底解决，例如，将数据操作语言－－DML，附加到输入参数）； c、SqlParameter 类指定存储过程参数的数据类型，作为深层次防御性策略的一部分，可以验证用户提供的值类型（但也不是万无一失，还是应该传递至数据库前得到附加验证）。 缺点： 1.如果更改范围大到需要对输入存储过程的参数进行更改，或者要更改由其返回的数据，则您仍需要更新程序集中的代码以添加参数、更新 GetValue() 调用，等等，这时候估计比较繁琐了。 2.可移植性差 由于存储过程将应用程序绑定到 SQL Server，因此使用存储过程封装业务逻辑将限制应用程序的可移植性。如果应用程序的可移植性在您的环境中非常重要，则将业务逻辑封装在不特定于 RDBMS 的中间层中可能是一个更佳的选择。 区别一，存储过程保存在数据库里面，存储过程可以被连接此数据库的所有程序设计语言和程序使用，自定义函数不能。 区别二，存储过程可以有数据库管理软件修改，使得多层结构程序调整系统逻辑时，并不需要编译和分发程序。 区别三，存储过程执行中，不会引起网络流量，不占用程序服务器的内存和CPU资源。