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