接手维护一个项目,c#实现,.net框架,Model,Dao,Bussiness分层架构。
项目中的DB操作(增删改查)全部用存储过程实现。
我可以想到的坏处是:
- 如果更换数据库,则工作量会非常大。
- 接手项目维护,或者参与开发的人都必须掌握对应数据库的存储过程写法。
想问下全部用存储过程做有什么好处?
stackoverflow上有人给出从安全角度考虑的好处:
- you have to grant permissions directly to the underlying tables etc(授权级别)
- with a sproc, all the real-underlying schema information can be encapsulated/hidden away (SPs can be encrypted too)(使用存储过程可以对底层的数据结构信息做了相对的加密,因为服务器和数据库的通信过程中不会再出现表结构) http://stackoverflow.com/questions/1199886/stored-procedures-vs-no-stored-procedures-security-viewpoint
这个好处不是特别有用吧!
还有其他的吗?
强调存储过程是上代数据库为王时代的理念,在10年前oracle/sql server为主流的年代,通常都比较强调这个,直到今天还留有很大遗存。
目前基于java平台的项目由于强大的orm框架影响,常规已基本都放弃存储过程使用,.net平台由于历史遗留习惯和还缺乏一非常有力(业界统一的)的orm,所以还有很多项目保守旧有理念,以安全、性能等理由提倡由存储过程实现一个数据中间层。
实际的来讲,使用存储过程
优点
- 性能 - 极端情况下对性能有一定提升
缺点
- 缺乏版本管理
- 调试跟踪不便
- 单独的分层导致开发、维护成本提高
- 长时间历史维护后很容易和主体代码脱节
- 分布不便
总体来说,除非对性能有特殊极端的要求,且数据逻辑极度复杂导致在sql层和代码层面实现有非常大的性能差异(即使这两点其实大部分也都能通过设计解决),否则当前已经没有必要再使用存储过程了。
节省数据库客户端到服务器的来回通信及编解码开销。
我现在做的所有C#项目都没有用存储过程 考虑到的情况
1 sql语句调试简单,方便
2 实际项目中很少有切换项目 主数据库的。
3 存储过程调试困难,程序不整齐,维护困难
使用 ORM
如果按照团队开发的分工,前台页面和后台业务功能开发不是一个人,使用存储过程可以比较清楚的划分工作界限。
如果使用sql语句的话,前台和后台的配合就相对困难了,一方面写sql语句灵活性大,而且前台人员可以随意修改,出了问题难念扯皮。
我觉得还是用sql比较好,好处上面都已经讲到,我就补充点坏处把
全部用存储过程,意味着你把很多在php层面可以处理的业务逻辑都交给数据库来处理,系统访问量很高时,php容易水平扩展,而数据库的扩展比PHP的扩容要麻烦的多,还得解决延迟等系列问题,数据库永远都是瓶颈,尽可能减少它的压力,让它处理最基本简单的增删改查,其他的计算交给php,比如group by等.