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

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

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

主流是java写业务，现在有些小公司也采用sql写业务
我觉得能交给SQL的就交给SQL，这样你的业务逻辑就比较清晰与简单。
比较倾向于Java处理业务逻辑
业务逻辑一般都是java这边出了的  sql主要是管理你数据的存储的
大多数系统的瓶颈都是数据库,业务逻辑清晰?你只是转移了业务逻辑到sql罢了
应用层可以轻松的扩展,你数据库可不容易
没什么标准不标准的
我们就要求sql不承担业务逻辑,多表关联能少用就少用,只在列表查询用一下,其他时候都是单表查询
数据库只承担增删改查的职责,业务逻辑都应用层处理,虽然sql有时候会让你代码变得简单,但滥用sql会造成更严重的问题具体怎么做,你可以用jpa,或者mybatis的逆向工程,这样你可以简单的代码去查询数据,但这个并不能禁止你写复杂sql
你得制定规范
业务逻辑给java呀，有关操作数据库的用sql
比较反感一戳长长的SQL，我的做法是一张表封装成一个业务对象，并提供相关接口供其他模块调用。
前面各位兄弟都说了,
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耦合也会降低很多的。
如果公司要求，那就按要求的来，标准不标准你能改变吗？
如果能改变，当然是按MVC的模式来最好。除非你能一切皆存储过程，这样连java代码里的sql都不用处理，直接处理存储过程就行。
正常的模式应该是：
java处理业务逻辑，sql只处理跟数据有关的增删改查具体操作。
看情况，不过我觉得如果用Java来写逻辑的话，sql能被更好的复用。同一条sql返回一样的结果，可能到了不同调用的地方需要显示的结果不相同，这样用Java来处理逻辑更好。
数据库更多的是用来存储数据，业务处理这块主要还是交给java代码来处理。见过一个工作七八年的，身份证中间星号隐藏在数据库处理，那个用java代码处理起来更方便更快捷，诸如此类，java处理起来更快捷为什么要用sql呢？
Java处理业务逻辑
除非领导刀架在脖子上，不然还是java处理吧，看到一坨sql都头疼，优化到你怀疑人生
这选择要根据实际情况选择，选择因数很多，没有绝对写在java中好，也没有绝对的写在sql中好，只有最合适，只有适合的才是最好的，搞技术的也不要那么偏激一定要用啥，同一套方案不能打遍天下，不同公司环境同样的决定可能产生不一样的结果，更多在于根据自己公司当前实际情况因地制宜抉择。简单举几个例子比如跟你公司类型有关，互联网公司和传统企业肯定是不一样的，传统企业的业务系统经过多年发展业务非常复杂而且平台比较老，不是你一般的增删改查这么简单，基本上是已经形成生态全部重构成本非常非常高，且没有一定要重构的必要性，可能大部分的业务都不在java中都是写在存储过程，这种情况业务逻辑写在存储过程sql中肯定是最合适选择，而且方便运维，如果是互联网公司特别是新创业公司业务基本上很简单，用的技术也是目前最新的，处理业务场景相对传统企业来说简单多了，多表关联也较少，基本上会写在java中。比如还跟平台有关，现在技术发展这么快，相信很少有几年的公司平台只有一个，老的平台业务很多写在sql中偏多，新的平台写在java中偏多，老的平台也不可能一刀切到新平台。比如还跟项目有关，有的平台适合如果是你老平台项目优化原来就是用的存储过程与sql，足够相信公司不会让你花很大成本去改成java，除非吃饱了撑着了让你浪费成本做无用功，新的平台一般会做新业务开发写在java中一般比较多，也有从老系统迁移过来的，新的开发人员一般不理解业务会进行折中选择。比如还有跟应用场景有关，有的场景适合写在java中，有的场景适合写在SQL中，比如同一个库大批量或很频繁的操作数据从一张表插入另一张表，这种情况就不需要把数据查询到应用层再从应用层写入数据库，直接写在SQL中是最好了没有网络开销，如果是跨数据库读写，肯定写在java中处理是最好的还有跟公司、客户的管理政策、网络安全也有关的，可能很多时候公司政策决定了你的技术选型反正我们新的平台最开始尝试创新全部把老业务改造写在java中有失败的案例也有，投入过成本远远超出预期效益颇微，最终结果就是你们部门口碑掉下去了，还有你懂的复杂业务处理写存储过程SQL中没有优化好反复读写数据导致性能瓶颈、系统响应慢、故障问题引起客户投诉的的也很多，最终结果就是可能要向客户检讨、批评等等，也会有你懂的。。还有系统响应体验不仅仅是跟开发有关，跟最开始系统软硬件架构、部署硬件设备性能、部署方式、部署容器、系统链路、网络等都有关系最后还是那句根据实际情况因地制宜抉择，当前环境、业务场景下哪个适合选哪个，技术最终目的是服务人的，不是人被技术憋死的。
比较倾向于Java处理业务逻辑
复杂的业务逻辑建议用java代码去处理，SQL处理的话，要是到时候数据库升级或者迁移了，那就很可能要重新写
Java处理业务逻辑是正规、正常的处理方式，通过Java处理业务逻辑可以做负载均衡、性能调优、分布式等提供高系统处理能力的方法，而且理论成熟、工具完整。
在项目中要具体问题具体解决，看你要解决的问题是什么，如果性能已经达到或者接近要求，仅SQL因为复杂，建议还是攻克一下技术难关；如果性能要求更高，那就花时间重构。
重构的复杂度比较高，要有充分准备。
SQL写业务逻辑必然没有java好。客户后期需求来的时候改SQL语句是十分麻烦的。而业务逻辑代码在JAVA中是比较好处理的。再说服务器端的业务逻辑处理能力并不比数据库慢。
sql出了问题没法排查，会哭的老铁
个人观点，java处理的话，看起来会清晰一点，业务逻辑看起来好一点。sql处理的话，性能会更好一点，但看起来就不清晰了
简单的逻辑，sql也容易看懂的，那么sql就好了。
如果比较复杂，从维护角度，放代码更好。实际情况中，并没有区分那么明显，要平衡性能和可读性以及开发量。
大多数系统的瓶颈都是数据库,业务逻辑清晰?你只是转移了业务逻辑到sql罢了
应用层可以轻松的扩展,你数据库可不容易
你两能不能給个联系方式
大多数系统的瓶颈都是数据库,业务逻辑清晰?你只是转移了业务逻辑到sql罢了
应用层可以轻松的扩展,你数据库可不容易
你两能不能給个联系方式
?
我觉得你习惯用哪种就用哪种，相信自己，个人觉得JAVA写业务就七，八张表比较麻烦，还是建议用业务SQL好一点