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

出来多少年的 ORM 框架不就是你要的东西

100%洪水猛兽

没有吧，公司里面所有的系统都用了。

我维护过离职人员写的存储过程，这个东西的使用，我有两个问题：1. 执行出了问题，只能写表记录异常、错误信息？ 2. 存储过程和 Java 等语言实现相同的功能，在代码上存储过程是否更不易理解。

有
就是全球最大的 ERP 软件，德国思爱普 SAP 的 abap 语言。

abap 就是进阶版本的 SQL 语言，这个 sql 语言不但能操作数据库，还能用来描述用户交互界面。

存储过程的逻辑，在我们这占了最起码 30%
稍微复杂一点的数据交互，不用存储过程，慢的要死。

甚至 xml 都是洪水猛兽,超过 5 行根本看不懂,存储的语法和 bat,shell 有得一比,一般人看不懂,不像 java,python 那么直接

有学习门槛的东西，都有可能被找借口躲避

不会用不好管理而已，实际上用的好的话，性能很不错

当项目管理起来还行，不管理直接上数据库随便改那就是洪水猛兽。

存储过程还有一个问题：可移植性差
如果需要支持不同的数据库，一般就没法用存储过程了

不同的东西有不同的使用场景啊。
说是邪教的，无非是因为他们的使用场景不适合用存储过程罢了。
给你一台 1TB 内存 128 核心的服务器跑 Oracle 数据库，用户数量就 1 万人，业务逻辑常年不多变，你告诉我为啥不用存储过程。

如果存储过程和后端的业务逻辑是两班人马写, 并且 存储过程 可以静态分析, 那么 存储过程 才可以接受.

性能问题, 更应该用别的方式优化, 比如调整结, 异步, 分布式, 缓存等.

银行都是存储过程

个人觉得存储过程的问题，主要还是团队人数太多的时候，管理不善带来的。 新旧人员交接，互相关联的业务多个存储过程和代码里面的业务交叉影响等。 存储过程本身倒是没什么大问题。

哪个高级语言没有操作 DB 的 DSL ？完全满足你这几个要求。

谈 SQL 色变，那是因为不熟悉，系统性学过 SQL 的开发者很少，给存储过程加过断点的更少。

你好是的，debug 和版本管理简直灾难，虽然有时候设一些 sp 和 trigger 还蛮好用的

看情况. 对于互联网企业来说, 存储过程本身就是没必要的. 互联网企业本身业务非常简单, 几乎无外乎 CURD.
但是对于 SAP, 用友, 久其, 任我行那些 ERP 系统, 以及四通一达的那些 WMS 系统来说, 存储过程就是解决复杂需求的利器. 哦对, 也包括电信运营商与银行. 它们的存储过程更加复杂, 但存储过程对他们来说也往往是必然的选择.


业务逻辑越是复杂, 存储过程的就越是有存在的必要.

哦对, 铁路的 TRS 后面的业务逻辑全都是存储过程.

等你维护到几百个储存过程的古老项目就知道了，每天写代码都感觉自己在学习黑魔法

我这里还有一套系统全是视图存储过程触发器，其中有些看都不想看。

然不是

大把部系就是架

客端直 就是存程

因为国内大部分公司的业务就是 MySQL 撑起来的，绝大多数程序员写了十几年的代码，都极少接触 MySQL 之外的数据库。
稍微复杂的公司业务，比如银行电信，特别是 ERP 之类的，核心业务系统谁没事用 MySQL 这种弱鸡数据库

@totoro52 也不容易被炒

不是，学习成本罢了

感觉是时代变化了，我进的第一家公司就有大量的存储过程，函数，触发器。那些基本上都是 08-12 年间留下来的代码。后来的观念就是重视程序，尽量不依赖数据库处理逻辑。现在所在的公司已经完全没有数据库层面的逻辑了

我不用它完全是觉得这玩意就是石器时代工具，连关系数据库都是过于原始了。

你司有一大群 DBA 么？没有就别用
上面说某些行业有用的，你看看他们有多少 DBA ，或者每年花多少钱从 Oracle 买 DBA 服务

一个是难维护，另外难以横向扩展，说人话就是不容易通过加机器解决性能瓶颈

主要是维护困难，假如你是接手的程序，出了数据问题让你排查，给你一段过千行的 sql ，重新阅读理解排查，那滋味儿酸爽

我认为存储过程不是优势，而是无奈

并不那么绝对吧，一切技术的应用都看场景，但是一般情况下，都没有必要使用存储过程。

存储过程就是洪水猛兽。

大学刚毕业进了某头部保险公司，做的项目是收付系统，核心业务是 “核算 核销 对账”，这些核心功能全部由 Oracle 存储过程实现，SQL 总行数在 5w 行左右，涉及到 90 多张表，其中最大的一张表 495 个字段。

当领导安排我来核算几亿条保单数据的收付情况时，面对上万行的存储过程，我人直接傻了，恨不得马上离职，这也成为了我职场上一辈子的心理阴影......

写的时候是非常的开心，但是不要叫我维护，或者解决 bug 。那可不行

@totoro52 同意，我曾经维护过 5w 多行存储过程，涉及到 90 多张表，最大的表 495 个字段

存储过程 极度违反 存储与业务分离

@sanmaozhao #11 这句话是真的 迁移的过程能多混几个工作日可能都不止

存储过程也不是洪水猛兽，没有 DBA 的公司，开发者写存储过程后，他离职了没人记得这玩意。后面接手的人可能永远不知道这玩意存在。

不要开历史倒车

项目中整了几个，多年维护下来：极其的好用，极其的反人类

不知道 这有文档么?
没有文档前提下能有代码容易看懂么?

@tanhui2333 这个不是开历史倒车. 是有些场景下只有存储过程合适. 在大并发高一致性高实时性的场景. 比如银行. 你不可能说这边支付完了过了好几秒余额才减掉吧.

你都招不到会用这个东西的人。

我们 MES 都是存储过程，6-7K 个。 无所谓了，职场都有工具人。

看行业的，比如银行、ERP 系统、财务管理系统这些，存储过程是大量使用的。而互联网行业，我认为如无必要坚决不使用存储过程。

你自己写的时候，绝对不会认为是洪水猛兽。
等接手的人维护修改时候，绝对会喷这是洪水猛兽

所以，是不是洪水猛兽，要看站在谁的角度

数据量大，业务逻辑复杂，存储过程非常好用

之前公司的架构师设计的前端直接掉存储过程，设想非常好，实际应用中 一个简单的见面掉几十上百个过程 ，前端人都麻了

到 2025 年为止，我还找不到一个编程语言，除了存储过程，能够在 0.5 秒内改变系统的逻辑，不用发布，不用测试，走任何流程，不留下任何记录，而且门槛极低。

如果你认为上面我说的全是优点，那显然应该用。

@ericguo 数据库可以开 Audit ，不可能不留任何记录

@yangzzzzzz 类似的行为艺术架构师，还是有想法的：核心人员无法被裁

没有专职 DBA ，不要用存储过程

@imnpc 不一定 好多 30 多岁的老开发, 对数据库的理解可能比 DBA 还深刻.

你要是存储过程文档很详细,用就用了,前提有 DBA

以前 维护 ERP 的时候，就是前端用的那种 我都忘记叫什么了，就是前端直接调用数据库的存储过程
整个系统主要是依赖存储过程

维护、升级特别复杂，数据库绑定，绑定到版本，数据库如果语法有修改，存储过程都要重来

现在 接口系统，都是 分布式、数据业务分离，存储过程就不合适了

存储过程的一个问题是 sql 没有普通的高级语言语法丰富，导致阅读书写代码要困难一些，然后 debug 比较困难，我知道 sql server 的 sp 是可以 debug 的，不知道 oracle 行不行，mysql 是不行的。

成本低，不用招专门的大数据开发，我们之前一天百亿条数据，用 8 个 mysql 来跑存储过程，成本比用数据湖低的多

曾经刚毕业的时候，在一家做银行软件的公司，那个时候用的也是存储过程，阅读起来极其费劲，维护特别困难，当然对于高手来说，也不是啥事儿，但是如果是对于初入职场的人来说，去维护一些边角料的功能你都会觉得很恶心。

记得后面离职 1 年多的时候时候，这套核心系统终于被彻底重构了，存储过程的那部分逻辑全部用 java 重写了。

上一次看到这个词应该还是在 2009 年刚工作的时候～～～～

存储过程 不就是个 low code

@lujiaxing 也不能这么说，像我以前做证券，一样有支付什么的啊，也不用存储过程。像支付宝什么的，也不见得非要用存储过程吧。

以前存储过程确实在这方面比较好用，所以用得多，后面人们慢慢发现了缺点就用得少了。但有些项目有历史包袱还是得接着用。如今微服务什么的，用得很多，现在缺点也逐渐暴露出来，以后怎么样还不知道。每个技术都有时代的局限性。

@sanmaozhao #11
@pipixiarwksb #36

有 AI 的年代，改写成不同语言，应该都不是啥问题吧。。


@dlmy #32

5W SQL 转成编程语言实现，复杂性会降低多少呢？感觉 SQL 实现一般都更简短呀。。

搞不明白,明明代码可以处理,非要写存储过程,搞得代码逻辑处理一半,存储过程处理一半,徒增心智负担

也很好奇，存储过程应该如何做版本管理？

@aureole999 银行的账务逻辑比证券复杂多了.

很多传统企业级、FinTech 用 IOE 之类的那套，量级不那么大，安全性第一，可以、但不是必须。

其他 ToC 尤其是国内这些：
1. 海量用户海量并发的，存储过程单点性能就不太合适了
2. 业务需求的快速迭代，存储过程开发和维护都是不合适的

国内很多企业去 IOE 的过程中，存储过程也越来越、很多团队已经消灭存储过程了。

老屎山，能不动，就不动；
新项目，能不用，就不用。

并不是,很难说现在的 flinksql 大数据那一套不算另一种方式的存储过程。 最主要是如何包装和平台化，让其他非开发人员也参与进来。 并且能够妥善的维护 而不是丢到数据库里就不管了。 所以还是屁股决定脑袋,你是 dba 还是开发 可能有不同的感受

你是不是在找“ORM”

@lujiaxing #65 银行的账务逻辑比证券复杂多了.
---------------------
无法认同。都是语言，不存在只有存储过程才能对应的业务逻辑。

存储过程当初出现的原因，是因为大型机，以及前后端分离的技术不成熟。但是随着云计算的出现，算力已经不成为问题，那么存储过程的语言问题就变成了阻碍，无法方便的重构，调试和缺少语法糖，都是影响开发效率的存在。

现在还在用存储过程的企业，只能认为是有历史包袱在，迫不得已的选择。

如果当年没有去 IOE 的运动，估计现在还有一大波的人在写存储过程。
存储过程写起来是爽，多表关联，批量更新，效率也非常高。大约 2014 年，2015 年之前的 ERP 系统，后面的业务逻辑基本上都是存储过程，银行系统，电力系统，大型企业的内部管理系统，基本上都是存储过程。
但是维护这玩意儿也是噩梦，没日志，debug 麻烦。有时候业务提交上来一个 bug ，你定位到了 bug 是在具体哪个存储过程导致的，然后要修这个 bug 的时候，有时候是很绝望的！
之前关于存储过程不是有这么一个冷笑话么，系统出现 bug 了，一个程序猿搞了两个礼拜，然后经理说，我现在有一个好消息和一个坏消息。好消息是我定位到了 bug 是在那个存储过程里面产生的，坏消息是这个存储过程有 3000 行。

@lujiaxing 经常帮老开发们优化数据库性能，存储过程写的屎一般，甚至表连个索引都没有，存储过程还用来各种抓取同步耗时且大量的数据

@jeffreyWang007
做得好的公司会和普通代码一样，导出成 SQL ，然后上传 SVN 或者 git 。
做的不好的公司就直接运行发布了，最多在存储过程里面写一下注释，把之前的逻辑注释掉，然后写新的逻辑

本地那种商业软件放心用 0.1QPS 都没有的 无所谓性能

你给 1KQPS+的互联网服务大众的系统数据操作都扔存储过程里 大概率卡到地球另一边

存储过程比直接写在应用代码里面，更难以调试，版本控制也难，同时 pgSQL 之类的数据库语言的表达能力也显著弱于应用层语言，倒不是说存储过程不能用，只是必要性越来越低，出于熟悉程度、调试之类的考虑，就慢慢被越来越淘汰了

只要弄好 单元测试 / 版本管理，什么语言都无所谓。

如果是复杂的存储过程我们一般都是自动转译的，sql 基本没办法调试，没必要在上面浪费人力。

新功能都不让使用存储过程，老代码里面有存储过程让能正常运行就行

@ytll21 不用存储过程, 用程序处理的话, 终归会有反复与数据库交互的过程. 十次八次的还好, 像某些银行那样的系统, 一笔交易涉及各种跨库跨表查询几十个 (尤其有不少还涉及到本地服务, 如水电气缴费, 地方分行/支行企业合作业务, 自动扣费业务/罚款等), 反复与数据库交互的这个通讯的成本是很高的. 一般来说银行的各种交易必须在几百毫秒之内结束, 而且不可以出现单据不一致的情况. 这与互联网企业的最终一致性要求是不一样的. 银行, 电信系统之类的, 要求的都是实时强一致性. 在这种需求之下, 存储过程是最好的. 至于研发难度, 反正也不是老板需要面对的事情. 有难度你们研发慢慢啃去呗.

@ytll21 当然, 如果系统没有这么强的一致性要求, 用存储过程就纯属是给自己找不自在.

我现在碰到的 一个业务 代码 30%基本校验 参数传递 然后调存储过程 70%逻辑在哪里 不恶心吗 真的很恶心

那存储过程要代码评审吗

@zbatman ，看来手势返回的那个帖子冒犯到你了

存储过程是历史遗迹，曾经很有用，但现在只剩缺点了……

优点非常诱人，直接消除了网络 io ；缺点也足够致命，复杂场景那就是没法维护，不知道以后是否可以用 ai 来协助。要用好还真不是三言两语能说清楚的。

有些人扯 orm 是什么情况？这特么是同一个应用场景的东西？

主要看是多少行的存储过程

现在有 ai 了，维护起来应该会比以前简单一些

旧时代的 CS 平台经常是这么玩的。

主要逻辑以存储过程存在于 DB 中。Client 主要用于界面展示，数据计算及各种逻辑大都使用存储过程。

优点缺点都是有的，有维护开发的人可以说道很多，现在使用这种架构的仍然不少。

到 BS 时代后，一般改用代码，也是 ORM 框架了。

你写写就知道了，一堆 CS 相关产品的公司仍然在用，去试试就好。

可能受 DDD 影响，觉得存储过程这种东西太依赖对应的数据库了，而数据库一般都是可替换的，涉及到核心业务就非常危险了，像你说的，如果未来与一种高级语言支持各类数据库的存储过程，用这个高级语言去编写核心业务，这个是可以接受的。

一旦换个 db 存储模式 直接爆炸 代码都不知道咋写

银行国产化了之后也不太用了

脱离具体业务谈这个就是耍流氓

如果是单体应用，未来扩展性也基本上一个 db 能抗住，那么存储过程其实是利器。写写注释即可。

@fffq 还有维护成本，这可比学习成本带来的成本高太多了

接手其他人写的存储过程做维护和加功能简直酸爽，天天骂娘

@idragonet 我接触的 mes 系统，用存储过程的还是少，有的公司真的如楼主所言，谈此色变，命令禁止。我曾经为了不写存储过程，写查询语句写了 200 多行，关联 10 多张表。

这个取决于出了问题谁负责，如果谁写的谁负责，那就 OK

@salmon5 软件行业，又不像建筑行业那样，出了问题终身刑责。写存储过程的人离职了，你怎么办？

@tohuer00 如果学建筑业那样，终身追责，事故入刑，那难维护的问题，应该会好一些。哈哈哈

@xiaomushen #97 那存储过程是个偷懒的方案，应该禁止使用

我们公司现在在翻新之前的一个系统，之前是基于.NET 开发的，里面的核心逻辑全在存储过程里面，我每天看的都想辞职了