前面各位兄弟都说了, 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层基本服务.来最终完成功能.
[quote=引用 5 楼 maradona1984的回复:][quote=引用 2 楼 weixin_40290083 的回复:] 我觉得能交给SQL的就交给SQL,这样你的业务逻辑就比较清晰与简单。
[quote=引用 2 楼 weixin_40290083 的回复:] 我觉得能交给SQL的就交给SQL,这样你的业务逻辑就比较清晰与简单。
81,094
社区成员
341,711
社区内容
加载中
试试用AI创作助手写篇文章吧