搜索
  • 大家对于存储过程是怎么看的？
  • 发布于 1个月前
  • 85 热度
    22 评论
很多开发者一提到 SQL 就“谈此色变”，觉得难以调试、难以定位 bug!最后就是一句话，就是这个东西碰不得，是邪教。存储过程这个东西存在这么久，不可能一无是处吧:
.有没有可能，像 TypeScript 转译为 JavaScript 一样，有一种高级语言可以：
.编译成各类数据库支持的 SQL （比如 PostgreSQL 、SQL Server 等）；
.根据目标数据库的特性自动优化生成对应代码；
.如果使用了目标数据库不支持的语法，比如在目标是 PostgreSQL 时用到了 SQL Server 的专有语法，那么编译器应能直接报错并给出明确提示；
.最好还能在开发阶段提供类型检查、智能提示和跨平台兼容性检查。
大家觉得存储过程真的是洪水猛兽吗？
用户评论
  • 搁浅双手
  • 以前维护过泛微的OA办公系统，那存储过程写的跟以前女人的裹脚布一样，又臭又长，搞了半天实在搞不定，最好只能连接他们上海总部的技术来排查
  • 2025/5/11 10:27:00 [ 0 ] [ 0 ] 回复
  • 世界的变迁
  • 现在存储过程用的比较少了主要还是技术的进步，这里的技术进步不仅是软件开发的进步，还有科技硬件的进步。从软件开发来看，现在的主流开发在操作数据库时都用ORM框架了，很少直接写SQL语句，所以现在很多程序员对于SQL的使用大部分还是停留在CRUD的地步，像存储过程，触发器等用的都比较少。从硬件科技进步的角度来看，现在的计算机算力资源都很强，不管是CPU还是GPU，还是网络宽带。而以前硬件资源紧缺，所以遇到系统性能问题就只能从数据库优化等方面去入手。而现在，只要你写的代码不是低级到把数据库连接放到循环语句里这种。就是用正常的ORM写的代码和用存储过程在性能上的差异完全可以被现在硬件资源覆盖。另外最后说一点就是：当系统中使用了大量的存储过程，那维护起来真的非常麻烦，特别是存储过程还不是一个人写的情况。
  • 2025/5/10 10:18:00 [ 0 ] [ 0 ] 回复
  • 蓦然回首
  • 很多传统企业级、FinTech 用 IOE 之类的那套，量级不那么大，安全性第一，可以、但不是必须。
    其他 ToC 尤其是国内这些：
    1. 海量用户海量并发的，存储过程单点性能就不太合适了
    2. 业务需求的快速迭代，存储过程开发和维护都是不合适的

    国内很多企业去 IOE 的过程中，存储过程也越来越少、很多团队已经消灭存储过程了。
    老屎山，能不动，就不动；
    新项目，能不用，就不用。
  • 2025/5/9 12:32:00 [ 0 ] [ 0 ] 回复
  • 天长地久

  • 如果当年没有去 IOE 的运动，估计现在还有一大波的人在写存储过程。存储过程写起来是爽，多表关联，批量更新，效率也非常高。大约 2014 年，2015 年之前的 ERP 系统，后面的业务逻辑基本上都是存储过程，银行系统，电力系统，大型企业的内部管理系统，基本上都是存储过程。


    但是维护这玩意儿也是噩梦，没日志，debug 麻烦。有时候业务提交上来一个 bug ，你定位到了 bug 是在具体哪个存储过程导致的，然后要修这个 bug 的时候，有时候是很绝望的！之前关于存储过程不是有这么一个冷笑话么，系统出现 bug 了，一个程序猿搞了两个礼拜，然后经理说，我现在有一个好消息和一个坏消息。好消息是我定位到了 bug 是在那个存储过程里面产生的，坏消息是这个存储过程有 3000 行。
  • 2025/5/9 12:29:00 [ 0 ] [ 0 ] 回复
  • 时间扯淡
  • 到 2025 年为止，我还找不到一个编程语言，除了存储过程，能够在 0.5 秒内改变系统的逻辑，不用发布，不用测试，走任何流程，不留下任何记录，而且门槛极低。如果你认为上面我说的全是优点，那显然应该用。
  • 2025/5/9 12:28:00 [ 0 ] [ 0 ] 回复
  • 旧城回眸
  • 看行业的，比如银行、ERP 系统、财务管理系统这些，存储过程是大量使用的。而互联网行业，我认为如无必要坚决不使用存储过程。
  • 2025/5/9 12:26:00 [ 0 ] [ 0 ] 回复
  • 入戏太深
  • 存储过程也不是洪水猛兽，没有 DBA 的公司，开发者写存储过程后，他离职了没人记得这玩意。后面接手的人可能永远不知道这玩意存在。
  • 2025/5/9 12:23:00 [ 0 ] [ 0 ] 回复
  • 都是戏子
  • 存储过程就是洪水猛兽。大学刚毕业进了某头部保险公司，做的项目是收付系统，核心业务是 “核算 核销 对账”，这些核心功能全部由 Oracle 存储过程实现，SQL 总行数在 5w 行左右，涉及到 90 多张表，其中最大的一张表 495 个字段。当领导安排我来核算几亿条保单数据的收付情况时，面对上万行的存储过程，我人直接傻了，恨不得马上离职，这也成为了我职场上一辈子的心理阴影......
  • 2025/5/9 12:20:00 [ 0 ] [ 0 ] 回复
  • 万劫不复
  • 感觉是时代变化了，我进的第一家公司就有大量的存储过程，函数，触发器。那些基本上都是 08-12 年间留下来的代码。后来的观念就是重视程序，尽量不依赖数据库处理逻辑。现在所在的公司已经完全没有数据库层面的逻辑了。
  • 2025/5/9 12:10:00 [ 0 ] [ 0 ] 回复
  • 撕烂的回忆
  • 因为国内大部分公司的业务就是 MySQL 撑起来的，绝大多数程序员写了十几年的代码，都极少接触 MySQL 之外的数据库。稍微复杂的公司业务，比如银行电信，特别是 ERP 之类的，核心业务系统谁没事用 MySQL 这种弱鸡数据库。
  • 2025/5/9 12:05:00 [ 0 ] [ 0 ] 回复
  • 花开在雨季
  • 看情况. 对于互联网企业来说, 存储过程本身就是没必要的. 互联网企业本身业务非常简单, 几乎无外乎 CURD.
    但是对于 SAP, 用友, 久其, 任我行那些 ERP 系统, 以及四通一达的那些 WMS 系统来说, 存储过程就是解决复杂需求的利器. 哦对, 也包括电信运营商与银行. 它们的存储过程更加复杂, 但存储过程对他们来说也往往是必然的选择.

    业务逻辑越是复杂, 存储过程的就越是有存在的必要.
    哦对, 铁路的 TRS 后面的业务逻辑全都是存储过程.
  • 2025/5/9 11:55:00 [ 0 ] [ 0 ] 回复
  • 轻描淡写
  • 个人觉得存储过程的问题，主要还是团队人数太多的时候，管理不善带来的。 新旧人员交接，互相关联的业务多个存储过程和代码里面的业务交叉影响等。 存储过程本身倒是没什么大问题。
  • 2025/5/9 9:15:00 [ 0 ] [ 0 ] 回复
  • 恍惚忆起
  • 如果存储过程和后端的业务逻辑是两班人马写, 并且 存储过程 可以静态分析, 那么 存储过程 才可以接受.
    性能问题, 更应该用别的方式优化, 比如调整结构, 异步, 分布式, 缓存等.
  • 2025/5/9 9:07:00 [ 0 ] [ 0 ] 回复
  • 尘封的记忆
  • 不同的东西有不同的使用场景啊。
    说是邪教的，无非是因为他们的使用场景不适合用存储过程罢了。
    给你一台 1TB 内存 128 核心的服务器跑 Oracle 数据库，用户数量就 1 万人，业务逻辑常年不多变，你告诉我为啥不用存储过程。
  • 2025/5/9 9:00:00 [ 0 ] [ 0 ] 回复
  • 奢华的爱情
  • 我觉得不仅存储过程是洪水猛兽，甚至 xml 都是洪水猛兽,超过 5 行根本看不懂,存储的语法和 bat,shell 有得一比,一般人看不懂,不像 java,python 那么直接。
  • 2025/5/9 8:43:00 [ 0 ] [ 0 ] 回复
可能感兴趣的话题