PLSQL 等等存储过程在现在时代背景下是否可以继续使用？

supabase 算现代系统吗？

业务逻辑靠
https://supabase.com/docs/guides/database/functions
https://supabase.com/docs/guides/database/postgres/triggers

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

> 几乎所有业务都是使用的 PLSQL 实现，java 实现的接口几乎就是透传

这种用法毫无疑问就是历史遗留问题，维护旧系统那就算了，新系统绝对不会这么使用。

> 在现在这个时代背景下，是不是还需要使用 PLSQL 实现业务？

存储过程的好处就是：

1. 负载发生在数据库服务器上。
2. 充分利用数据库的批量数据处理能力。
3. 充分利用数据库的事务能力。

能用到这 3 个好处之一的那些仅数据操作的逻辑，可以放到存储过程里。其他任何逻辑都应该在数据库外完成。业务逻辑肯定是不该放到存储过程里了。

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

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

-- 说了这么多, 感觉都是在甩锅. 强数据一致性到底是怎么实现的?

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

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

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

@mingl0280 一致性不是一定依靠存储过程，事务做得好，也能得到同样的效果，然后就是交易强一致，其他边缘弱一致，或者说最终一致

存储过程是把所有的逻辑过程，变成 PL/SQL 脚本，甚至可以理解为代码本身了
这样的问题是，调试、开发、并发，都有很大的缺陷
很多年前维护过，确实不利于大规模迭代开发，需求快速变更等

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

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

花巨资请 IBM 的专家来设计核算跟核销系统，核心逻辑就是 2 个存储过程，一个 8000 多行，操作 37 张表；一个 5000 多行，操作 29 张表...

优点是逻辑都是写在存储过程中，需求变动不需要重启服务器，改 SQL 就完事了。

缺点是平时得养着这些 IBM 的专家，因为出问题了我们没法排查，压根就看不懂写的什么。

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

@Aksura 我是觉得，用 java 取数据，可能要频繁的网络 IO,一次 http 请求 fetch 很多数据用 java 计算会很慢，再加上用 sql 写业务还是有局限性，直接用存储过程计算会不会更方便，PLSQL 能处理更复杂逻辑，然后计算完结果直接传给 java ，这样会更高效更灵活

@FkingMan 你提到的这个 IO 的情况，以及如果是从数据库取出一堆数据再在 java 里加工，那就等于是在 java 里自己又实现了一遍数据库的处理功能。正好对应我上面提到的第 1 和第 2 点，所以应该在数据库中完成计算，再把计算完成的结果传回到 java 中进行下一步处理。我的观点是，是存储过程里要完成的计算应该严格限制在表的操作上，“业务”的逻辑不只包含表的操作，不能因为 PLSQL 是过程化的语言，就把业务逻辑都写进存储过程里，甚至到了把 java 等后端完全当作一个透传的接口的地步。