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

[liuidetmks]

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

---

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

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

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

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

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

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

[xuanbg]

存储过程不是洪水猛兽，但滥用存储过程是。任何技术都有其适用场景，该用就用。不会用可以学，也可以找会的人来做。但因为自己不会某项技术，或者无法驾驭利用好这项技术，就视其为洪水猛兽的话，我只能说“你高兴就好”

[RicardoY]

当你需要把逻辑放的离数据足够近，且需要事务支持的的时候，存储过程（或者 trigger ）非常的有效

[shakoon]

对于需要进行日终批处理的业务系统来说，存储过程简直方便出天际。把公共逻辑做好解耦，充分运用好函数、包，写好注释，存储过程的维护和其他语言一样，没有什么难的。可惜现在的各种国产数据库对存储过程都支持得很不好（甚至很多不支持的），离开 oracle ，以后确实会很少再用到存储过程了。

[ivvei]

@aureole999 国内哪个证券公司不用存储过程？

[ivvei]

@shakoon 不是很多都是 pg 改吗？ pg 的这点能力还是远强于基于 mysql 的那些的。我看国产数据库很多还会考虑和 Oracle 的兼容性。

[aureole999]

@ivvei 我不在国内

[shakoon]

@ivvei #105 涉及到多表关联的游标的，性能上差异明显啊。那些号称兼容性好的，不过是售前的吹嘘，真到了实施阶段，骑驴难下，很多代码都得重写。

[chihiro2014]

不如代码用 ORM 操作数据库方便，存储过程 debug 比较麻烦，维护很痛苦。我们组有个存储过程，每天跑都不一定跑成功

[ssxwcz]

这玩意写起来太费劲了，debug 麻烦，维护起来成本太搞了，而且写起来动则几千行，看的头都要爆炸了。

[Rehtt]

之前接手的一个项目页面查询要等几分钟而且可能超时，一看代码全是存储过程，后面一狠心重构了一次用程序去处理逻辑，sql 只单纯 select *，现在这个时间已经优化到几秒

[x2ve]

1.存储过程难管理 2.定位问题较难 3.移植困难 ；
几千行的存储过程看起来人晕乎乎的

[miscnote]

我在电力行业，也用存储过程，代码多的也有几百上千行。我不喜欢存储过程，主要是一段时间过后，哪怕自己写的存储过程，拿过来一看也看不懂了。

[pinkGo]

主要就是 debug 麻烦，要一行一行的 print 定位问题点。

[Dogtler]

开发这么多年，一次存储过程都没用到过。

[Gilfoyle26]

@JaysonHope #95 关联 10 多张表这个一看就是架构师没有很懂业务

[xiaoxinshiwo]

也不能说是洪水猛兽，只是排查问题和 debug 的时候让人头大，本地不能重现的问题，线上太难查了

[kkwa56188]

业务逻辑稳定的, 银行政府大企业, 写好了跑稳定了 十几年不用动它了的那种, 用起来还是舒服.
当然 前端仔一天需求能改三次的, 写存储过程那是自己找不痛快.

[MrHarson]

@sanmaozhao 这个是不可避免的。对数据库特性、功能使用的越多，移植起来就越困难

[Lao9]

没有必须，

传统上 toB 类开发习惯使用，原因主要是商业数据库功能支持所有 PL 类数据类型，ADT ，高级语言如 OO 类特性，与数据库执行层结合紧密，可以利用编码优势缩短执行路径，各类全局、局部缓冲获得性能优势。

互联网企业 toC 领域习惯将数据库当成存储数据的容器，业务逻辑放在应用端。

数据处理密集型的传统企业，与互联网企业之间的数据处理模式不同，也有历史原因。

很难说谁好谁坏，实现功能即可。

但库内 PL 的优势是明显的，除了直接在生成码端有优势，在库内可以广泛利用复用、缓冲等技术获得性能优势。但这个视数据库能力，使用者的技术水平。

假设免费开源数据库支撑的业务，没必要花费力气研究这个，如使用昂贵商业数据库的开发者，数据库产品自身在这块的能力与业务要求决定了是否需要花费额外时间掌握数据库级 PL 。