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

存储过程这个东西存在这么久，不可能一无是处吧
有没有可能，像 TypeScript 转译为 JavaScript 一样，有一种高级语言可以：

编译成各类数据库支持的 SQL （比如 PostgreSQL 、SQL Server 等）；

根据目标数据库的特性自动优化生成对应代码；

如果使用了目标数据库不支持的语法，比如在目标是 PostgreSQL 时用到了 SQL Server 的专有语法，那么编译器应能直接报错并给出明确提示；
最好还能在开发阶段提供类型检查、智能提示和跨平台兼容性检查。

出来多少年的 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 这种弱鸡数据库

也不容易被炒

不是，学习成本罢了

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

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

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

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

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

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

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

存储过程就是洪水猛兽。

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

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

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

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