很早的时候，我被我们领导灌输过一个思想，我们领导当时是做WEB出身的，他非常重视WEB的功能。在他眼里，数据库只是存放数据的箱子，不应该把过多的业务逻辑交给数据库去处理，应该只把他看做是存放数据的箱子，我们当时是用MySQL + php，那时候MySQL比较弱一些，不支持存储过程、触发器，事务等等，正好符合我们领导所提倡的理念。
后来接触了ERP，发现数据量很大，全部用VB等处理效率低、速度也慢，采用存储过程效率高，而且有些Bug，新功能只要在数据库服务器上进行修改存储过程就可以了，客户端都不用修改程序，感觉这个存储过程很强大，而且通过存储过程还可以做其他软件的数据库接口，自从那以后就疯狂痴迷于存储过程、数据库技术，经常研究这些方面的技术。
又过了些日子，接触了Oracle，发现与SQLSever里的存储过程不兼容，有些写法、用法、理念差距也很大，移植问题是个很大的麻烦，虽然理论是完全可以移植的，但是要维护2套这样的系统，麻烦很多，所以开始渐渐的放弃写存储过程这个爱好了，尽量写一些简单的SQL语句的组合，尽量把商业逻辑都写在C#里，好调试些，随着对C#语法的深入理解，商业逻辑写在C#里的开发速度，比写在存储过程里还快了很多，再接着对系统整体功能的定位，渐渐放弃了局部功能的优化思想，以考虑全局为重，不差那么0.1秒的性能速度提高，不在乎这些一点点的差距。
最近几年，由于对面向服务编程的深入理解，彻底放弃写存储过程了，尽量商业逻辑都写在C#里，因为客户有可能是买了正版的Oracle或者购买了正版的SQLServer, 他们希望你的程序能跑在他们的正版数据库系统上，而不是为了使用你的系统，又重新购买另一套正版软件。
基于存储过程的数据库脚本的主要缺点是调试起来麻烦，数据库中的表字段变动了，也不提示关联错误，也没有版本控制，很容易丢失脚本程序，而且人人都有一个本地数据库，很容易把存储过程搞乱套了，最后会导致谁都不知道到底哪个才是最新的存储过程，而且给上百个存储过程起个合理的名称，这个命名工作统一规范化也是个要命的问题。
把商业逻辑写在C#里的好处就很多了，有相应的版本控制器，以前的代码也可以找出来，不怕丢失代码，有些修改程序等造成的错误，在开发环境编译阶段就能发现错误在哪里，好进行关联修正，多种版本的数据库上移植也简单些，也不用同时两边作战，又要维护数据的版本，又要维护程序的版本，发布时也会遇到2方面都需要更新的问题。还是单边作战比较简单一些，同时与其他系统的接口等，交给相应的服务程序进行处理，由服务程序来负责与其他系统的交互，这个交互又比底层数据库的交互强大很多。
我曾经写过一个小软件，里面大量采用了存储过程，给我的痛苦总结下来是，1. 数据库中的表进行了修正了，我不知道哪几个存储过程需要修正？
2. 有时候手上好几个数据库，测试来测试去，很容易不知道到底哪个是最新的，特别是过了一年半载，再去找对应的数据库时，这个问题很明显。
3. 调试C#程序很容易，调试存储过程，相对麻烦一些。
4. 参数有变动时，还要修改存储过程的参数，有时候还有关联的存储过程需要修正，很折腾人，而且运行了，才能发现这些问题。
3. 还有这个程序只能跑在SQLServer上，还好我们用的都是D版，想安装就装了，也不要钱，若真要钱，那不是开玩笑的。
现在我们开发的很多系统里，根本看不到存储过程的影子了，当然我们也不是走极端，在平时一些简单的系统里，还真没多大必要用到存储过程，能不用就不用吧，多一事不如少一事，现在总结已经走过的路，感觉还是商业逻辑尽量写在C#里是省心省力的正确道路。