存储过程真的是洪水猛兽吗?

3 天前
 liuidetmks

很多开发者一提到 SQL 就“谈此色变”,觉得难以调试、难以定位 bug
最后就是一句话,就是这个东西碰不得,是邪教


存储过程这个东西存在这么久,不可能一无是处吧

有没有可能,像 TypeScript 转译为 JavaScript 一样,有一种高级语言可以:

12170 次点击
所在节点    数据库
117 条回复
xuanbg
2 天前
存储过程不是洪水猛兽,但滥用存储过程是。任何技术都有其适用场景,该用就用。不会用可以学,也可以找会的人来做。但因为自己不会某项技术,或者无法驾驭利用好这项技术,就视其为洪水猛兽的话,我只能说“你高兴就好”
RicardoY
2 天前
当你需要把逻辑放的离数据足够近,且需要事务支持的的时候,存储过程(或者 trigger )非常的有效
shakoon
2 天前
对于需要进行日终批处理的业务系统来说,存储过程简直方便出天际。把公共逻辑做好解耦,充分运用好函数、包,写好注释,存储过程的维护和其他语言一样,没有什么难的。可惜现在的各种国产数据库对存储过程都支持得很不好(甚至很多不支持的),离开 oracle ,以后确实会很少再用到存储过程了。
ivvei
2 天前
@aureole999 国内哪个证券公司不用存储过程?
ivvei
2 天前
@shakoon 不是很多都是 pg 改吗? pg 的这点能力还是远强于基于 mysql 的那些的。我看国产数据库很多还会考虑和 Oracle 的兼容性。
aureole999
2 天前
@ivvei 我不在国内
shakoon
2 天前
@ivvei #105 涉及到多表关联的游标的,性能上差异明显啊。那些号称兼容性好的,不过是售前的吹嘘,真到了实施阶段,骑驴难下,很多代码都得重写。
chihiro2014
2 天前
不如代码用 ORM 操作数据库方便,存储过程 debug 比较麻烦,维护很痛苦。我们组有个存储过程,每天跑都不一定跑成功
ssxwcz
2 天前
这玩意写起来太费劲了,debug 麻烦,维护起来成本太搞了,而且写起来动则几千行,看的头都要爆炸了。
Rehtt
2 天前
之前接手的一个项目页面查询要等几分钟而且可能超时,一看代码全是存储过程,后面一狠心重构了一次用程序去处理逻辑,sql 只单纯 select *,现在这个时间已经优化到几秒
x2ve
2 天前
1.存储过程难管理 2.定位问题较难 3.移植困难 ;
几千行的存储过程看起来人晕乎乎的
miscnote
2 天前
我在电力行业,也用存储过程,代码多的也有几百上千行。我不喜欢存储过程,主要是一段时间过后,哪怕自己写的存储过程,拿过来一看也看不懂了。
pinkGo
2 天前
主要就是 debug 麻烦,要一行一行的 print 定位问题点。
Dogtler
2 天前
开发这么多年,一次存储过程都没用到过。
Gilfoyle26
1 天前
@JaysonHope #95 关联 10 多张表这个一看就是架构师没有很懂业务
xiaoxinshiwo
1 天前
也不能说是洪水猛兽,只是排查问题和 debug 的时候让人头大,本地不能重现的问题,线上太难查了
kkwa56188
1 天前
业务逻辑稳定的, 银行政府大企业, 写好了跑稳定了 十几年不用动它了的那种, 用起来还是舒服.
当然 前端仔一天需求能改三次的, 写存储过程那是自己找不痛快.

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://yangjunhui.monster/t/1130319

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX