从疯狂痴迷数据库存储过程到彻底放弃他(信息化系统从基于数据库技术到基于服务理念的转变)
2009-05-20 14:53 通用C#系统架构 阅读(4807) 评论(51) 编辑 收藏 举报很早的时候,我被我们领导灌输过一个思想,我们领导当时是做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#里是省心省力的正确道路。