过去四年，一直在维护一个银行的借记卡系统，核心功能是由外国人开发，使用 PLSQL ，几乎所有业务都是使用的 PLSQL 实现，java 实现的接口几乎就是透传，我一直有个疑问，在现在这个时代背景下，是不是还需要使用 PLSQL 实现业务？

需要的。跟钱有关的，搞个 Oracle 很合理。

那个年代的系统都是这样的，现代系统很少用了。

新系统一般不会再用了吧。但作为老系统替换成本还是很高的，而且一般收益也不大，吃力不讨好的事一般不会有人去做。

除非特别大的系统，实际上大部分系统用存储过程维护成本反而更低。但是，mysql 的计算性能，根本跑不了存储过程，云厂商又要忽悠大家用 mysql 。。。

传统行业做核心业务这块，大型机加 oracle 是可以承载的，但现在不会了，一是贵，二是供应链不安全。

现在这个时代有何不同？

plsql 挺优秀的，就是能用 plsql 只有 oracle.国内的 oceanbase 还有其他的一些数据库也模仿 oracle. post gres 倒是有些 plsql 的创新，能生成 restapi ，但是在 plsql 里头，最优秀的是对包的管理，缺的，麻烦的是对代码的版本管理和格式化。当然，今日，完全可以不用 plsql ，一定要尽量思考如何前端，后端分离

跟金融业有关的, 还是得 Oracle, 新版 (其实很久了)早就可以 把 plsql 直通 restful 了, 只是贵和生态绑定, 一般的创业公司用不起

银行系统，敢提取消存储过程的都是勇士。

现在银行核心早就禁止了存储过程了。

你高兴就好

我就在干这件事情

也就是说你们开发团队自己背数据库不一致的风险咯？

数据库不一致是啥问题，你是想说数据不一致？

比方说记账/事务写入比较复杂的时候，不使用存储过程难免遇到需要多次插入，如果这个过程中有部分数据库或者连接故障，这个不一致的风险和造成的损失肯定就要你们银行自己解决了。所以你们是自己扛了这部分的风险了吧？

见过这种设计，写一大堆存储过程和函数，美其名曰在线部署不需要重启服务器

我们这边的 ERP 系统 报表和单据就是存储过程 一个 sql 一千多行

是的，都 AI 时代了，总有人抱着祖宗之法不可变，殊不知，明朝和大清都灭亡好多年了，最后一任皇帝，坟头草都老高了。

为啥会出现多次插入？应急方案是啥？能否回退？业务如何规避？今晚能不能解决？防重放的设计咋写的？为什么能过评审，为什么代码能过 review ？测试为什么测不出来？业务为什么测不出来？平时的灰度吃屎了？如果上面的重重防线都被击穿，还造成了比较大的社会影响，那就麻烦主管科技的副行长去人行金管局解释一下了，毕竟这个改造任务是总行下达的嘛。

supabase 算现代系统吗？业务逻辑靠 supabase.com/docs/guides/database/functions supabase.com/docs/guides/database/postgres/triggers

Proc 是挺恶心的，代码乱飞 也就这些传统行业的老人愿意用

几乎所有业务都是使用的 PLSQL 实现，java 实现的接口几乎就是透传这种用法毫无疑问就是历史遗留问题，维护旧系统那就算了，新系统绝对不会这么使用。> 在现在这个时代背景下，是不是还需要使用 PLSQL 实现业务？存储过程的好处就是：1. 负载发生在数据库服务器上。2. 充分利用数据库的批量数据处理能力。3. 充分利用数据库的事务能力。能用到这 3 个好处之一的那些仅数据操作的逻辑，可以放到存储过程里。其他任何逻辑都应该在数据库外完成。业务逻辑肯定是不该放到存储过程里了。

历史原因用过程没问题新业务用过程要么是被逼无奈要么是有病维护难，定位问题难，扩展性差，招人也不好招

应急方案是啥？能否回退？业务如何规避？今晚能不能解决？防重放的设计咋写的？为什么能过评审，为什么代码能过 review ？测试为什么测不出来？业务为什么测不出来？平时的灰度吃屎了？如果上面的重重防线都被击穿，还造成了比较大的社会影响，那就麻烦主管科技的副行长去人行金管局解释一下了，毕竟这个改造任务是总行下达的嘛。-- 说了这么多, 感觉都是在甩锅. 强数据一致性到底是怎么实现的?

明白了，确实是直接把风险给银行开发了。谢谢指导。

＃10 他们认为只有存储过程才能实现强一致性,都这样了就随他们去吧

我觉得唯一的问题是：不利于架构演进和改造。

一致性不是一定依靠存储过程，事务做得好，也能得到同样的效果，然后就是交易强一致，其他边缘弱一致，或者说最终一致存储过程是把所有的逻辑过程，变成 PL/SQL 脚本，甚至可以理解为代码本身了这样的问题是，调试、开发、并发，都有很大的缺陷很多年前维护过，确实不利于大规模迭代开发，需求快速变更等

现在国家在各型企事业单位都在大力推信创，都想要换国产的系统。不知道这个会不会影响到。

我司的返利系统都是靠存储过程计的

花巨资请 IBM 的专家来设计核算跟核销系统，核心逻辑就是 2 个存储过程，一个 8000 多行，操作 37 张表；一个 5000 多行，操作 29 张表...优点是逻辑都是写在存储过程中，需求变动不需要重启服务器，改 SQL 就完事了。缺点是平时得养着这些 IBM 的专家，因为出问题了我们没法排查，压根就看不懂写的什么。

废话，出了事情为什么不甩锅？