题外话,为什么不用数据库的存储过程
1个回答
展开全部
不建议使用存储过程的原因
其一:各种数据库的存储过程语法相差很大,给将来的数据库移植带来很大的困难
其二:不利于版本控制,代码无法Diff和回滚,多人编辑无法同步。
虽然数据库建模工具可以把脚本保存为文件,然后进行Diff,但终究功能有限。
其三:编码不便,其实也就是说数据库脚本语言功能有限,
无法定义数组,集合,为了循环需要使用效率低下的游标
其四:调试功能不强。
虽然在数据库客户端工具里,也可以调试,却也和现在功能强大IDE集成工具的调试
却不可同日而语。而且现在一般调试是由应用程序发起的,从应用程序却又无法
跟踪调试回存储过程中。所以必须两处调试,终究不便。
其五:存储过程会调用函数,视图或者别的存储过程,但是数据库的编辑工具,
不像时下的开发工具,能够准确定位对象或对象方法,所以带来维护,修改的困难。
其五:现在大多应用级系统会分层处理,数据层,业务层,界面层。
我们把大量使用存储过程的C/S或者B/S系统称为两层半,也就是说存储过程就是我们
说的半层,也就是把大量业务逻辑放在存储过程里。业务逻辑往往是系统的核心所在,
往往修改会很频繁,存储过程的使用会带来修改困难,修改流程困难,调试麻烦,
所以付出的代价是很大的。
其六:面向业务编程,而不要面向数据编程。
面向业务编程,其实也就是之前我说的领域逻辑模式中的领域模型,也是我不赞成用存储过程
的根本原因。
如果大量用到存储过程,就势必会和数据表、字段、字段类型等等关系形数据库打交道,
面向对象的优势就体现不了,也就无从谈起继承,多态,设计模式等来适应业务变化。
很多J2EE的项目甚至不用存储过程,也照样开发的很好。
其七:也许会遇到业务逻辑特别复杂的情况,遇到这种情况,我的感觉是你应该回头看看业务建模是否合理。
其一:各种数据库的存储过程语法相差很大,给将来的数据库移植带来很大的困难
其二:不利于版本控制,代码无法Diff和回滚,多人编辑无法同步。
虽然数据库建模工具可以把脚本保存为文件,然后进行Diff,但终究功能有限。
其三:编码不便,其实也就是说数据库脚本语言功能有限,
无法定义数组,集合,为了循环需要使用效率低下的游标
其四:调试功能不强。
虽然在数据库客户端工具里,也可以调试,却也和现在功能强大IDE集成工具的调试
却不可同日而语。而且现在一般调试是由应用程序发起的,从应用程序却又无法
跟踪调试回存储过程中。所以必须两处调试,终究不便。
其五:存储过程会调用函数,视图或者别的存储过程,但是数据库的编辑工具,
不像时下的开发工具,能够准确定位对象或对象方法,所以带来维护,修改的困难。
其五:现在大多应用级系统会分层处理,数据层,业务层,界面层。
我们把大量使用存储过程的C/S或者B/S系统称为两层半,也就是说存储过程就是我们
说的半层,也就是把大量业务逻辑放在存储过程里。业务逻辑往往是系统的核心所在,
往往修改会很频繁,存储过程的使用会带来修改困难,修改流程困难,调试麻烦,
所以付出的代价是很大的。
其六:面向业务编程,而不要面向数据编程。
面向业务编程,其实也就是之前我说的领域逻辑模式中的领域模型,也是我不赞成用存储过程
的根本原因。
如果大量用到存储过程,就势必会和数据表、字段、字段类型等等关系形数据库打交道,
面向对象的优势就体现不了,也就无从谈起继承,多态,设计模式等来适应业务变化。
很多J2EE的项目甚至不用存储过程,也照样开发的很好。
其七:也许会遇到业务逻辑特别复杂的情况,遇到这种情况,我的感觉是你应该回头看看业务建模是否合理。
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询