定义
存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL 语句集，它存储在数据库中，一次编译后永久有效，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。
优缺点
优点（为什么要用存储过程）：
1.执行速度快，因为是预编译的，一次性编译，永久生效，直接调用存储名即可
2.减低网络流量，代码直接存储在数据库当中，所以不会产生太多的T-sql代码流量
3.增加安全性
a）通过向用户授予对存储过程（不是表）的访问权限，他们可以提供对特定数据的访问
b）增加代码的封装性，防止SQL注入
缺点：
1.存储过程的过多创建，一定程度上占用了数据库的内存，影响运作速度
2.可移植性差，因为存储过程依赖于库，例如当从Oracle迁移到MySQL，所有的存储过程都要重写
3.代码可读性差，维护修改难
存储过程对业务逻辑的应用
这里要提出一个关键词：业务逻辑
什么是业务逻辑？？
业务：是指一个实体单元向另一个实体单元提供服务；逻辑：根据已有的信息推断出合理的结论，合理的规律；
因此业务逻辑就是指一个实体向另一个实体提供服务，应该具备的规则与流程
想要封装公司的业务逻辑，存储过程是其中一种表达方式，或者封装成函数，再或者直接SQL语句去查询，在这里仅讨论存储过程
由存储过程的优缺点延申出来的问题：是不是业务逻辑稳定的，就特别的依赖使用存储过程？答案是yes
因为可移植性差、更改维护困难的缺点，导致应用要求稳定，像金融、银行等行业，业务逻辑稳定，安全要求高，存储过程还能增加安全性，减少SQL的注入，这简直完美；
然而像一些互联网产品传统开发中，就不建议用存储过程来封装业务逻辑，原因如下：
a）业务逻辑封装在存储过程中。对数据库的依赖性比较大。一旦要迁移数据库,比如从oracle迁移到mysql等，以前的业务逻辑都得重写(因为存储过程是具体的数据库系统产物,不同的数据库语法不同)。
b）其实在互联网高并发，大流量的情况下，成熟的做法都是，计算层交给web层，数据库只是存储数据。尽量少让数据库去做运算(也就是ifelse之类的逻辑判断)，不要让脚去做脑瓜子要做的的事情。从这个角度，就是要把计算数据，判断之类的都交给应用代码去解决。
c）方便扩展。遇到数据库性能瓶颈。单台数据库服务器永远会存在瓶颈的(极限)，是扛不住的。集中式最终会被分布式给替代，一般在互联网环境下偏向于使用分布式部署数据库。分布式通俗理解，要分库，拆分表。拆分到多台服务器上去。分散压力。如果业务逻辑封装在存储过程中。则不好这样子做。因为存储过程是依赖于某个具体的库的。把计算层放到web层，那么web端的程序只是从多个数据库服务器聚合数据即可了。
d）互联网应用频繁修改功能，需求变化快。