存储过程真的很难么?

2019-06-30 15:48:39 +08:00
 v2overflow

新领导要求不要用存储过程,说因为存储过程太复杂,后续的人不好接手... 要求所有数据的处理都读出来用 java 程序处理,比如复制一张表:先 select 到对象中,再把这个对象 insert 到目标表...和他说 CTAS,他说太复杂,和他说效率,他说可以加机器...

如果说过于依赖存储过程会对后续数据库迁移有影响我觉得是有道理的,但他貌似根本没想到这一层,而且既然用数据库了,不能用 SQL 实在不能理解

14551 次点击
所在节点    程序员
126 条回复
brust
2019-07-01 10:59:10 +08:00
有存储过程的项目就是一座屎山
不过有一个好处,如果自己维护简单,别人维护复杂
写出了别人难以维护或者无法维护的代码相当于增加自己的核心竞争力
当然前提是这个模块很重要,无法被重构的那种
wysnylc
2019-07-01 11:03:09 +08:00
首先存储过程是垃圾
其次业务逻辑在代码中没有丝毫问题,分布式就是要去 join 去子查询才能拆分数据库,join 会导致表之间关联锁死无法拆分
JohnSmith
2019-07-01 11:11:29 +08:00
过来人经验,sql 服务器经常莫名高资源占用,没有 trace 信息,找不到原因,代码无法维护,难以 debug。重构也相当困难,害人害己!
存储过程可以类比成现代框架中的 faas,但是缺少必要的 trace,metrics,log 以及统一的控制后台。
在类比一下,就和微服务架构缺少 devops 一样~
onionKnight888
2019-07-01 11:13:58 +08:00
维护过上古业务的存储过程,真是恶心吐了
JohnSmith
2019-07-01 11:17:52 +08:00
任何团队项目都需要重视工程规范和工程标准化
FrankHB
2019-07-01 11:19:44 +08:00
@Actrace SQL 名义上确实是“查询”(“ Q ”)语言,但规格上至少包含 DML/DDL/DCL。以查询为中心的 SQL 名义上是声明式语言,但实际上已经是大杂烩了。
实际实现野心更大,什么乱七八糟的功能都想掺和(很多所谓内置函数的干活附会到“查询”上也是可以的,但本质早就和 DB 无关了),给 DBA 偷懒以外就是给手贱不懂正确选型的开发喂屎而已。
“可扩展”的存储过程算是这种不切实际的鸡肋野心的进一步实现。半吊子 UI 能顶几个靠谱的 API 呢,谁用谁知道,是不是混了斯德哥尔摩综合症就难说了……
l00t
2019-07-01 11:20:53 +08:00
从没觉得存储过程不好维护…… 写得是不是容易让人理解,这得看写的人的风格,和读的人的习惯。同一个操作,你可以写成很多人理解有困难的集合运算,也可以像别的语言一样游标里 for 一下逐条处理。要说行数太多,也完全可以拆分成多个函数和存储过程,甚至加入 package,和别的语言有啥大区别?纯粹是技术栈的问题罢了。

不能版本控制更是扯谈。在数据库里编译运行的就不能把代码拉出来写成脚本单独管理了?

另外写存储过程的语言不是 SQL !它只是能无缝集成 SQL 罢了,本质上和 SQL 还是两种不同的语言。

不容易横向扩展倒是真的。
VictorJing94
2019-07-01 11:23:36 +08:00
存储过程是很好的解决方案....
jsnjfz
2019-07-01 11:29:36 +08:00
看过几千行存储过程的飘过。。。其实不算复杂的,但是不利于管理
ericgui
2019-07-01 11:32:29 +08:00
rockyou12
2019-07-01 11:35:47 +08:00
任何系统(软件也好,盖房子造飞机也好),性能都不是最重要的,健壮性才是,而且是用血的经验总结出来的。

上面还是有部分回复觉得存储过程没问题,你要是有个存储过程跑了几年而且不会去改那才是没有问题。我们现在生产就有业务依赖存储过程,每年总有 1、2 次会有死锁然后要手动重启。好像不是大问题但每次都只有客户说了我们才知道,体验极差。

可能又有人说这是你们数据库维护水平不行,废话,你是领导同样的钱,或者给你同样时间让你学习,你是要精通数据库何种边边角角功能,还是精通业务开发能快速把业务写好 bug 又少的。
wupher
2019-07-01 11:44:38 +08:00
它们都只是技术而已,使用的情况么,看场景。

CS 程序员和产品会更喜欢存储过程。比如 XX 管理系统,XX 财务系统,主要业务逻辑都是使用存储过程封装。到客户那边修改逻辑实现,去数据库中改下存储过程即可,而不是使用 Delphi、C#、VC 什么的重新编译一个客户端或者 DLL,再部署。

但是在 Web 后端看来,这个解决方案就坑了。你写成 Java、C# 、Python 什么的,可以在无数应用服务器上并发运行。写成存储过程,就只能在数据库里面跑了。性能相差可能数据级别。存储过程,后面如果碰上数据迁移,比如 Oracle 转 MySQL、MySQL 转 HBase 基本上全得重新开发,而后端服务不受此影响。

都是抉择,无非取舍而已。
l00t
2019-07-01 12:30:19 +08:00
@rockyou12 #91 死锁和存储过程有啥关系?同样的代码你换个别的语言写就不死锁了?出现死锁,首先要排查出真正的原因,而不是推到存储过程上面。
lihongjie0209
2019-07-01 12:44:29 +08:00
@l00t 存储过程怎么排查死锁问题?
l00t
2019-07-01 12:45:38 +08:00
@lihongjie0209 #94 你别的语言怎么排查存储过程就怎么排查啊。
Vegetable
2019-07-01 12:48:30 +08:00
主要还是这门技术不够现代化
jiom
2019-07-01 12:54:51 +08:00
之前交接前辈的储存过程,我看了一个月,8K 多行。回想一下,想哭
lihongjie0209
2019-07-01 13:07:06 +08:00
@l00t 打断点, dump 线程, 写日志 存储过程可以做到哪一步?
q397064399
2019-07-01 13:09:53 +08:00
Structured Query Language

干好 Query 的事情就好了,迁移这些东西 说得不好听点,除了一行 SQL 跟 update insert 能搞定的事情,
最好不要用 SQL,存储过程无法调试,MySQL 那个报错又是反人类中的反人类,而且这东西没有
Trace 没有 Log , 鬼知道线上迁移的时候会出什么幺蛾子,用 Java 迁移 至少知道哪一块出了问题


------
另外你真的遇到了一个好领导了,我之前在的一个公司 领导恨不得把存储过程 人手普及一下,
说实话很多数据库的东西 都可以扫进垃圾堆了。

另外 DBA 如果看不懂代码操作了什么,我一般都是建议 用 Java 直接生成中间的 SQL 脚本 打死也不用存储过程
l00t
2019-07-01 13:10:38 +08:00
@lihongjie0209 #98 每一步都可以啊

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

https://tanronggui.xyz/t/578730

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

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

© 2021 V2EX