最近工作用到了存储过程，这里就简单的给大家描述一下我对存储过程的心得体会。
一、存储过程是什么?
定义:存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL语句集，存储在数据库中，经过第一次编译后再次调用不需要再次编译，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。存储过程是数据库中的一个重要对象
说白了,就是一堆sql语句的合并,然后中间加了一点控制逻辑。
以oracle 为例,其基本语法为:
Oracle存储过程基本语法 存储过程
1 CREATE OR REPLACE PROCEDURE 存储过程名 （param1 in type，param2 out type）
2 is/as(创建视图的时候as，创建游标的时候用is,平时的时候无大体区别)
3 变量 类型（范围）；
4 begin
5 执行体
6 end 存储过程名;
实例:
create or replace procedure pro_test(
pi_id in varchar2,
pi_name out varchar2
)
is
begin
select cname into pi_name from tb_user where id=pi_id;
dbms_output.put_line('name:'||pi_name);
end pro_test;
二、存储过程的优缺点?
使用存储过程这么几个好处
1、执行速度快,存储过程只在创造时进行编译,以后每次存储过程都不需要重新编译，而平常的sql语句没执行一次就编译一次，所以使用存储过程可以提高执行速度。
2、减少了网络通信,党对数据库进行复杂操作时(如对多个表进行增删改查),可以将复杂操作用存储过程封装起来与数据库提供的事物处理结合一起使用，如果用程序来完成的话,可能会执行多个sql,建立多次与数据库的连接，而使用存储的话,则只需要与数据库连接一次就行了。
3、可复用性高,重复使用,可减少数据库开发人员的工作量。
4、安全性高，可设定只有某次用户才具有对执行存储过程的使用权。
缺点：
1、可移植性差,不同的数据库对应的存储过程语法不同,所以在移植的时候可能会出现问题
2、sql本身是一种结构化的查询语言，只是加上了一些逻辑控制，还是属于过程化的，当面对一些复杂的业务需求的时候，过程化的处理会比较麻烦
三、关于存储过程使用的争论? 文章引用于http://blog.csdn.net/zy1691/article/details/3742780
我不倾向于尽可能使用存储过程，是这么认为的：
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复杂，或者数据交互多且中间数据最后不会用到，使用存储过程。其他凭经验吧。