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