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

[liuidetmks]

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

---

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

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

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

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

• 如果使用了目标数据库不支持的语法，比如在目标是 PostgreSQL 时用到了 SQL Server 的专有语法，那么编译器应能直接报错并给出明确提示；

  最好还能在开发阶段提供类型检查、智能提示和跨平台兼容性检查。

[roundgis]

當然不是

大把內部系統就是兩層架構

客戶端直連數據庫 邏輯就是存儲過程

[Mrun]

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

[roundgis]

@totoro52 也不容易被炒

[fffq]

不是，学习成本罢了

[yvyvyv]

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

[skydcnmana]

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

[pkoukk]

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

[wetalk]

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

[carytseng]

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

[zbatman]

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

[bk201]

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

[dlmy]

存储过程就是洪水猛兽。

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

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

[werls]

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

[dlmy]

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

[cenbiq]

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

[pipixiarwksb]

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

[Felldeadbird]

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

[uyZL3221XZ2xGZ3D]

不要开历史倒车

[sumu]

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

[back0893]

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