业务逻辑是放在 Java 好还是放在 sql 好？

金融，电信，医疗都是存储过程。

这种问题还有争议吗？肯定代码里啊

对于不需要维护的还是放 sql 里面吧

我们部门现在有个项目就是大部分逻辑都是在 sql 里，然后老大说要整改全部移到 java 里，目前改的人痛苦的想死（之前的 sql 是另一个人写的。。。）

如果用 spring 全家桶，难道没有这方面的惯例吗？（像 ror 的 ActiveRecord 专门处理连接数据库 ）

这个问题 10 年前，在 ITeye 还叫 javaEye 的时候不就讨论过了吗？
只有非常稳定的，基本不变动的业务，才适合放在存储过程里，因为存储过程的调试成本是非常高昂的，你去找个有经验的 DBA 试试。就算是有经验的 DBA，和有经验的码农放在一起，后者调试代码的成本也比前者调试 SQL 的成本低的多。所以只有像银行，医院，12306 这样的，业务成熟基本不变的地方，才会放存储过程。互联网这种需求一天 3 变的地方你业务放存储过程是嫌自己头铁加班加的少吗？
另外还有一个历史原因，早年的数据库，本质是个操作系统，可以看一下当年 IBM 的盖世之作 IBM System R，DB2 的前身，看见人家叫什么（操作系统 R ），自身的性能，是可以把当年的应用层开发语言的性能吊起来打的，而且当年计算机硬件资源又很匮乏，哪像现在，阿猫阿狗随便买个云都是 4 核 8G 的，spring boot 架起来直接就能跑。当年那是“不得不一定要优化程序提升性能才能正常上线”。所以性能在当时比应用层语言强处很多的存储过程就自然落入了开发者的眼里了。
现在，数据库很大程度上变成了数据仓库，搞分析有各种查询引擎，流处理，一般性查询业务应用层技术开发的很快，成本又低，JVM 优化了这么久，再加上硬件提起来后，大部分场合也吃的住了，存储过程这种开发调试代价高昂的东西，自然就边缘化了

@beyond98 哈哈，我刚好相反。老大是数据库出身，要把业务都存储过程实现，关键点是让我写他审，只能硬着头皮干了。

以前在一家金融公司就是放 sql 里,后来问一个熟人他在的金融公司也是这样的,看评论也是 推论 ====> 是不是金融公司都这样

作为外行，我犹豫过，“数据清洗和筛选逻辑是在 SQLite 里完成还是读取后用 Pandas 处理”。

@ikaros 是哪种金融公司呢？是自己做项目的互联网金融？还是向银行或大公司提供金融系统外包服务的公司？

@zw1one 自己做产品的

@night98 #9 啊 我孤陋寡闻了，客户端不直连 db 吗？

以前的 Oracle 和 db2 那些上古数据库很多不都是直接写存储过程的吗？

使用 orm 就是为了不写 sql

@ikaros 看什么类型的金融公司，传统金融公司的业务都已经固定了，追求的是两个方面，安全，对一致性要求相当高，算错一分钱都是大事；其次是性能，毕竟传统业务的客户数量也不低的，转账业务每天量也挺大，数据一致性问题，传统金融公司都是靠着单点机器性能硬顶（可能再过一二十年，NewSQL 才能慢慢的普及进去取代传统的 RDMS ）所以相当依赖数据库事务，遵循严格的数据库设计范式，这种情况下，业务全放存储过程肯定安全的多啊，放代码层？请问你编程功力如何？能实现严格的事务逻辑吗？实现之后性能又如何？
新的互联网金融公司都是靠着花里胡哨的业务骗钱的，今天一个活动明天一个促销，本质就是大街上卖吆喝，自然也就用互联网公司的方式了，业务都丢代码里，市场上的 Java 码农真便宜真香

@SilencerL #4 管家婆 erp，就是一大堆存储过程，二次开发一脸懵逼

你如果要强一致性，那只能放在数据库里

@zw1one #6 这么说的人都是浅视的，当你做业务拆分的时候就知道哪个好了

知道我今天为什么在加班么？ 250 行的 SQL 真是太难调试了...

我司批量添加记录的操作就是直接用的存储过程，传极少参数就 ok 了，出错了还能回滚，实际使用体验不错