java处理业务逻辑还是sql处理业务逻辑？

[vipyjb]

公司目前都比较习惯用sql处理业务逻辑，就是在dao层写很长的sql语句，基本不大用java写业务逻辑，但这样数据库服务器压力较大，处理性能较低，而且SQL优化起来也比较的复杂，现在想用JAVA处理业务逻辑，但跨表较多情况下 关联7、8张表以上，业务代码也会相当复杂，一般好的做法是什么呢？有没有什么标准做法？

[cwmlow]

我记得以前一位大佬说过的话：数据库只是作为存放数据的工具，仅此而已。

[明夕何夕-]

业务逻辑交给代码，数据库负责少部分数据存放的逻辑。

[三生万物2022]

这选择要根据实际情况选择，选择因数很多，没有绝对写在java中好，也没有绝对的写在sql中好，只有最合适，只有适合的才是最好的，搞技术的也不要那么偏激一定要用啥，同一套方案不能打遍天下，不同公司环境同样的决定可能产生不一样的结果，更多在于根据自己公司当前实际情况因地制宜抉择。

简单举几个例子

比如跟你公司类型有关，互联网公司和传统企业肯定是不一样的，传统企业的业务系统经过多年发展业务非常复杂而且平台比较老，不是你一般的增删改查这么简单，基本上是已经形成生态全部重构成本非常非常高，且没有一定要重构的必要性，可能大部分的业务都不在java中都是写在存储过程，这种情况业务逻辑写在存储过程sql中肯定是最合适选择，而且方便运维，如果是互联网公司特别是新创业公司业务基本上很简单，用的技术也是目前最新的，处理业务场景相对传统企业来说简单多了，多表关联也较少，基本上会写在java中。

比如还跟平台有关，现在技术发展这么快，相信很少有几年的公司平台只有一个，老的平台业务很多写在sql中偏多，新的平台写在java中偏多，老的平台也不可能一刀切到新平台。

比如还跟项目有关，有的平台适合如果是你老平台项目优化原来就是用的存储过程与sql，足够相信公司不会让你花很大成本去改成java，除非吃饱了撑着了让你浪费成本做无用功，新的平台一般会做新业务开发写在java中一般比较多，也有从老系统迁移过来的，新的开发人员一般不理解业务会进行折中选择。

比如还有跟应用场景有关，有的场景适合写在java中，有的场景适合写在SQL中，比如同一个库大批量或很频繁的操作数据从一张表插入另一张表，这种情况就不需要把数据查询到应用层再从应用层写入数据库，直接写在SQL中是最好了没有网络开销，如果是跨数据库读写，肯定写在java中处理是最好的

还有跟公司、客户的管理政策、网络安全也有关的，可能很多时候公司政策决定了你的技术选型

反正我们新的平台最开始尝试创新全部把老业务改造写在java中有失败的案例也有，投入过成本远远超出预期效益颇微，最终结果就是你们部门口碑掉下去了，还有你懂的。。。复杂业务处理写存储过程SQL中没有优化好反复读写数据导致性能瓶颈、系统响应慢、故障问题引起客户投诉的的也很多，最终结果就是可能要向客户检讨、批评等等，也会有你懂的。。

还有系统响应体验不仅仅是跟开发有关，跟最开始系统软硬件架构、部署硬件设备性能、部署方式、部署容器、系统链路、网络等都有关系

最后还是那句根据实际情况因地制宜抉择，当前环境、业务场景下哪个适合选哪个，技术最终目的是服务人的，不是人被技术憋死的。

[guishuanglin]

前面各位兄弟都说了, 1, 大公司 正规, java写业务, 用单表查询, 比如: 你关联 7-8张表, 最后结算还是只到 1-200个ID用来查数据, 那就找出ID 用 IN来单表查, 性能与7-8张表关联肯定要快. 我们有个省级项目测试过, 客户表 约2千万, 其它资料表也是上千万的, 数据表约 50亿行, 有些数据表 有400亿行. 关联查询几分钟才出结果, 如果单表用 IN 3秒左右. 所以这情况, 业务应在java中处理, 让查询SQL尽量是单表, 条件是主键, 或者是索引. 2, 如果项目不正规, 要求速度快, 尽量结束合同, 就想怎么玩就怎么玩, 没办法解决性能问题, 合同才是最重要的, 公司领导想怎么玩你就怎么玩. 3, 等到公司想优化的时候, 再说吧. 中国软件做不好, 就是与整个环境有关的, 所以一个人做到自己的事就行, 我们改变不了环境. (因此你想用什么标准模式, 接口, 范式, 是需要时间的, 除非公司有积累) 4, 我们公司的做法: 首先dao: 　把每张表操作都做成服务/微服务/或才jar包都可以, 规范对每张表的操作, 但是api必须完整, 工作量大非常大(可代码生成). 然后biz :　 把服务封装成业务层服务, 比如: 微信接口中[统一下单业务服务], 业务层的服务可以用事务来操控, 也可以用硬编码 if之类控制, 业务层是调用dao层各表的基本服务来实现的, 是根据业务组合了对表的操作. 最后展现层: action之类, jsp之类调用 主要是业务层服务, 部分也调用dao层基本服务.来最终完成功能.

[王福强]

java 处理比较好点，可以吧逻辑分的细点，然后数据库压力会小很多，而且sql耦合也会降低很多的。

[月亮的天空]

Java处理业务逻辑是正规、正常的处理方式，通过Java处理业务逻辑可以做负载均衡、性能调优、分布式等提供高系统处理能力的方法，而且理论成熟、工具完整。 在项目中要具体问题具体解决，看你要解决的问题是什么，如果性能已经达到或者接近要求，仅SQL因为复杂，建议还是攻克一下技术难关；如果性能要求更高，那就花时间重构。 重构的复杂度比较高，要有充分准备。

[ಡBollಡ]

SQL写业务逻辑必然没有java好。客户后期需求来的时候改SQL语句是十分麻烦的。而业务逻辑代码在JAVA中是比较好处理的。再说服务器端的业务逻辑处理能力并不比数据库慢。

[河岸飞流]

sql出了问题没法排查，会哭的老铁

[guishuanglin]

我见过一个上市公司的营销系统, 50%是用存储过程, 这个看公司而定

[晨泽]

比较倾向于Java处理业务逻辑

[老鼠拧刀满街找猫]

复杂的业务逻辑建议用java代码去处理，SQL处理的话，要是到时候数据库升级或者迁移了，那就很可能要重新写

[香草天空Sky]

个人观点，java处理的话，看起来会清晰一点，业务逻辑看起来好一点。sql处理的话，性能会更好一点，但看起来就不清晰了

[桐柏小仙]

这个没有标准，还是要看实际情况吧

[爱码叔]

简单的逻辑，sql也容易看懂的，那么sql就好了。 如果比较复杂，从维护角度，放代码更好。 实际情况中，并没有区分那么明显，要平衡性能和可读性以及开发量。

[云闪付大家庭]

引用 5 楼 maradona1984的回复:

[quote=引用 2 楼 weixin_40290083 的回复:] 我觉得能交给SQL的就交给SQL，这样你的业务逻辑就比较清晰与简单。

大多数系统的瓶颈都是数据库,业务逻辑清晰?你只是转移了业务逻辑到sql罢了 应用层可以轻松的扩展,你数据库可不容易[/quote] 你两能不能給个联系方式

[maradona1984]

引用 28 楼 云闪付大家庭 的回复:

[quote=引用 5 楼 maradona1984的回复:][quote=引用 2 楼 weixin_40290083 的回复:] 我觉得能交给SQL的就交给SQL，这样你的业务逻辑就比较清晰与简单。

大多数系统的瓶颈都是数据库,业务逻辑清晰?你只是转移了业务逻辑到sql罢了 应用层可以轻松的扩展,你数据库可不容易[/quote] 你两能不能給个联系方式[/quote] ?

[geller2010]

引用 10 楼 guishuanglin 的回复:

前面各位兄弟都说了, 1, 大公司 正规, java写业务, 用单表查询, 比如: 你关联 7-8张表, 最后结算还是只到 1-200个ID用来查数据, 那就找出ID 用 IN来单表查, 性能与7-8张表关联肯定要快. 我们有个省级项目测试过, 客户表 约2千万, 其它资料表也是上千万的, 数据表约 50亿行, 有些数据表 有400亿行. 关联查询几分钟才出结果, 如果单表用 IN 3秒左右. 所以这情况, 业务应在java中处理, 让查询SQL尽量是单表, 条件是主键, 或者是索引. 2, 如果项目不正规, 要求速度快, 尽量结束合同, 就想怎么玩就怎么玩, 没办法解决性能问题, 合同才是最重要的, 公司领导想怎么玩你就怎么玩. 3, 等到公司想优化的时候, 再说吧. 中国软件做不好, 就是与整个环境有关的, 所以一个人做到自己的事就行, 我们改变不了环境. (因此你想用什么标准模式, 接口, 范式, 是需要时间的, 除非公司有积累) 4, 我们公司的做法: 首先dao: 　把每张表操作都做成服务/微服务/或才jar包都可以, 规范对每张表的操作, 但是api必须完整, 工作量大非常大(可代码生成). 然后biz :　 把服务封装成业务层服务, 比如: 微信接口中[统一下单业务服务], 业务层的服务可以用事务来操控, 也可以用硬编码 if之类控制, 业务层是调用dao层各表的基本服务来实现的, 是根据业务组合了对表的操作. 最后展现层: action之类, jsp之类调用 主要是业务层服务, 部分也调用dao层基本服务.来最终完成功能.

400亿是什么鬼？

[峡]

我觉得你习惯用哪种就用哪种，相信自己，个人觉得JAVA写业务就七，八张表比较麻烦，还是建议用业务SQL好一点

[guishuanglin]

[/quote] 400亿是什么鬼？[/quote] 一张表 400亿行记录.

[人海中浮沉]

我遇到过业务逻辑基本用sql实现的，是那种统计类型的业务，数据库也是几千万级的，而且多表关联，我觉得像这种业务，要么用搜索引擎，要么分表，不然效率真的低。而其实放到代码中，逻辑是清晰了，但效率也差不多，比如先关联两张表得得结果再去写一个方法去关联另外的表，效率一个样，除非你用异步调用，好很多