如果使用数据库,大家是否会把业务逻辑放到存储过程?
灵感之源
由 灵感之源
发布于 2013年09月05日
无人欣赏。
我从第一个使用数据库的商业产品开始都是用存储过程,复杂业务逻辑完整并可被多放使重用,维护方便,安全。想像复杂的逻辑在应用服务器和数据库传递,还有注入,不能临时表游标等,问题多了。
存储过程的缺点就是偶尔的cache plan因为参数 sniffer或者corrupted,要折腾一下。还有容错这块看怎么做了,如果在sp吞了调用端又难以调试。对批量数据传递进来处理有点麻烦譬如用xml做参数,如果直接ad hoc那可以随便拼接。。。但我还是推荐存储过程。。。cache那是双刃剑看怎么用。
共12条回复
楼长
·
tinyfool
回复于 2013年09月05日
其实还是一个架构设计问题,如果真的需要用一些比较淫巧的手段,一定要有清晰的结构,隔离等等
2楼
·
灵感之源
回复于 2013年09月05日
做存储过程也是一个separation of concerns的做法啊,如果在代码里面写SQL,既不容易改,也把控制和数据逻辑混在一起了
3楼
·
tinyfool
回复于 2013年09月05日
我记得我刚玩Sql Server的时候还是蛮喜欢存储过程的,后来发现要移植的时候很麻烦,后来就不用Sql Server了
4楼
·
灵感之源
回复于 2013年09月05日
现在用啥数据?MySQL还是NoSQL?
5楼
·
akunamotata
回复于 2013年09月05日
能放存储过程当然放存储过程了,维护起来也容易,特别是统计。 还有就是能用数据库定时任务,尽量用数据库定时任务,总比代码定时任务强多了。
6楼
·
tinyfool
回复于 2013年09月05日
我现在主要是MySQL,没啥需要NoSQL级别的负载啊
7楼
·
灵感之源
回复于 2013年09月05日
同意akunamotata,我都忘记了任务那块了。
听说腾讯还是在用MySQL做QQ的存储?
8楼
·
stros
回复于 2013年09月06日
我的经验有点不同,一直是尽量避开存储过程。项目型的统计多的可以用存储过程吧,这东西不好移植,并且在数据库切分之类的操作时会有麻烦,业务逻辑一般不耦合数据层的东西。
本帖有12个回复,因为您没有注册或者登录本站,所以只能看到本帖的10条回复。如果想看到全部回复,请注册或者登录本站。