在 Java 业内, 难道多表联合查询都是复杂问题吗?

（虽然不是 javaer ）不知道你说的具体苦在哪里。

如果用 Hibernate ORM + Spring JPA 的话，图中这种需求应该是不需要写 SQL / HQL 的，Repository 里一句接口函数声明就好了。

如果 Entity 对应字段没标 eager fetch ，可能需要写点 HQL 标记字段为 join fetch 。

如果对应方法需要分页，用 Pageable 接口就可以了。

@Senorsen java 中实现肯定可以实现, 只不过又需要一堆的 interface/service/mapper/xml/sql 而已, 感觉有点拖了内裤放屁的意思. 谁让 java/Spring 是如此"严谨"的工程哪

@skyworker 别人回的都是真在解决问题，就是加注解和参数，然后注解要怎么配置，哪有你说的那么复杂。我看你倒没想解决问题，只是想阴阳怪气，为了这碟醋专门包的饺子吧。

我觉得 java 业内最宝贵的财富之一就是这么多年积累下来的这些方案和方法。

@skyworker 不至于，我 1L 说的，基本只需写个：

https://gist.github.com/Senorsen/edd0fb0306fbc022be5f636eeb9c9736

调用处直接使用 employee. findByCompanyId(companyId, PageRequest(分页参数即 offset limit 等)) 就好了，没有那么多你说那些

还可以试试 EntityGraph 这个注解

确实没很好的方案, 大多都是写 XML 的 SQL, 很难受, 或者是 Spring Jpa + QueryDSL 但可以试试 Bean Searcher , https://github.com/ejlchina/bean-searcher/blob/master/README.zh-CN.md

@skyworker 这些一般都是自动生成就好，只是为了保持相同的结构，新人直接过来也能很短的时间内熟悉代码（只是属熟悉业务需要点时间）。接口我们这小厂实际使用场景不多，其他的设计还是有用的。
还有 java 最爽的一点就是重构的时候，可以看到所有引用，然后方便去检查改动是否合理，有没有漏改或者忽略什么。

是啊，用 java 的都是笨比，op 最聪明了呢。
认真回答下：java 主流规范目前不建议多表联查，有数据规模上升后的查询效率问题，分库分表后的重构困难等。复杂的 sql 往往会耦合业务，造成一些排查难、debug 难，是非常不推荐的开发方式。ORM 框架也没往这方向发力。
如果真想联查，用 @select 写个 sql ，mybatis 也不是非要写 xml 的。

@skyworker #2 见你楼上的回复，当你使用 Spring Data JPA 以后，多表联合查询没那么复杂，只需要接口中定义一个方法，方法名旁边用注解再定义一个 SQL （用原生 SQL 而不用 HQL/JPL 都没问题）。（前提是实体类和接口已经定义过了，这个相对于 PHP 这些可能还是麻烦一些，但这是一次定义终审省事，并且这已经涉及强类型语言跟弱类型语言的对比了。）

@rykinia #3 现在用 Spring Data JPA 的并不多，如果是用 Mybatis ,即使是 Mybatis Plus, 那楼主说得是没错的。

google 一下不麻烦，即使是 mybatis 也已经有成熟的强类型编程的多表关联解决方案，至于你图上这种字符串满天飞的方案，个人觉得不咋地

超过 3 张稍大的表，性能就会变慢，所以楼主该不会没有写过复杂业务吧。不会吧不会吧不会吧。

（或许是 javaer 与 xxx 魔怔了，可别是个谁都来 java 这里问问题了，求求了。）
要问问题就好好问，别天天阴阳怪气

@RedBeanIce 业务偏向于企业内部 ERP 系统, 特点是 字段多(一个表中可能有 50 个字段), 并且每个表中的数据行数 5 年累计出来, 不会超过 5K 行, 不是"百万并发"的行业

@RedBeanIce 我们手头的系统, 甚至不用特地加索引也行, 所以多表关联很常见, 甚至关联 4-5 张表也有

@nothingistrue 的确是 Mybatis

@skyworker 建议可以试试好好设计表，多写单表。

这种设计，这种代码，，，维护起来非常痛苦。

@skyworker 你就不是来理性讨论的