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