@garyxi24

现在很少写 join 和子查询，因为数据库基本都是分库分表，或者是微服务物理隔离的，所以 JPA 比较合适。

如果不是这种场景，需要手写复杂 SQL ，可以尝试一下 MyBatis 分页插件，比如：MyBatis-PageHelper 、MyBatis-Plus ，但是这俩插件在一些场景下可能会有 Bug ，而且代码质量也堪忧。

也可以参考我写的分页插件： https://github.com/yihleego/mypages
使用了 ANTLR4 分析语法树，支持多种使用场景。

可以试试 H2 ，是用 Java 实现的，虽然是关系型数据库。

我觉得 ORM 能解决你的痛点，比如 JPA ，而不是 MyBatis 。

像 Elasticsearch 这种，分页性能更差，基本上都不用分页，通常用滚动搜索。

你用习惯了 Java 再转 Go ，大概率很长一段时间都无法适应，尤其是生态方面。
如果说 Java 是全副武装的话，那么 Go 就只穿了条裤衩配了双拖鞋就上去干了。

显然，你自己心里是清楚的，不要抱侥幸心理，被抓到不仅可以开除你，还可以报警抓你。如果是仲裁收集证据，你大可以放到明面上来。

我不觉得 GitHub 一定要放对岗位有用的 repo ，上班已经写的够多了，下班还要写？饶了我吧。
并不是所有人都喜欢蹲 Bug 提 PR 硬蹭，难道平时写写自己喜欢的小工具和文档算减分项吗？对别的技术感兴趣，到你这怎么就变成一文不值了。我觉得对技术有热情就是好事，比那些下班回家一趟刷抖音的强多了。

不贴 GitHub ，不用 GitHub ，甚至都不知道 GitHub 的人，大部分对技术不感兴趣吧。

dynadot

互联网用数据库就存个数据，根本不用特性，计算都通过应用服务。
公司有一套 MySQL 的生态，而且开发者比较熟悉 MySQL ，也就没有理由换其他数据库了。
同理，如果有公司熟悉 PostgreSQL ，那他也没有理由换成 MySQL 。

除非 PostgreSQL 宣布下个版本支持高性能分布式，否则 MySQL 不会被替代。

不敢

我也卖一个 https://草.dev/

@wxf666 不会，多 join 一张表会有一点开销，但是不至于差；分库分表不允许使用 join 。

示例：user 、department 、user_department_rel 各 100 万条，共 300 万条数据，两张表联查和三张表联查的开销几乎无差别。

两张表联查结果：

test>
select *
from user u
join department d on u.department_id = d.id
where u.id = 100000
[2022-07-29 10:24:46] 1 row retrieved starting from 1 in 116 ms (execution: 76 ms, fetching: 40 ms)

test>
select *
from user u
join department d on u.department_id = d.id
where u.id > 100000
limit 10000,10
[2022-07-29 10:24:47] 10 rows retrieved starting from 1 in 127 ms (execution: 89 ms, fetching: 38 ms)

三张表联查结果：

test>
select *
from user u
join user_department_rel udr on u.id = udr.user_id
join department d on d.id = udr.department_id
where u.id = 100000
[2022-07-29 10:24:47] 1 row retrieved starting from 1 in 125 ms (execution: 76 ms, fetching: 49 ms)

test>
select *
from user u
join user_department_rel udr on u.id = udr.user_id
join department d on d.id = udr.department_id
where u.id > 100000
limit 10000,10
[2022-07-29 10:24:48] 10 rows retrieved starting from 1 in 138 ms (execution: 96 ms, fetching: 42 ms)

@wxf666 按我的理解，数据库范式只是一种建议，而且其过于学院派，并不适合所有实际场景。
尤其是互联网行业，更倾向于实用派，例如 MySQL ，其作用仅为储存数据，计算基本上都放在应用服务，有些公司的设计规范中，甚至连外键都禁止使用。

@wxf666
根据 OP 的业务场景，一般是如此。应该考虑到「用户系统」和「组织架构」的隔离性，即「用户系统」可以拆出来单独使用，「组织架构」也可以拆出来可以与其他的「用户系统」配合使用，而不需要改造代码（或者说只需要微调）。

如果是商品（ SPU ）和商品库存（ SKU ）这种业务，则应该用直接关联，如：在 sku 表中存 spu_id ，因为他们业务上本身就是强关联的，而且一般是处于同一个 domain 中。

@hahaFck
不推荐使用 join ，是因为互联网业务的很多场景下都可能无法使用 join ，例如：
- 微服务：物理隔离
- 分库分表：数据库实例不同
- 数据中台：数据存在中台，只能通过接口方案
- 更换数据库（多数据库）：去 Oracle 化、MySQL -> TiDB 、RBD -> KVDB 等，不同数据库语法可能不兼容。

如果没有使用 join ，只需要替换 Repository 层即可，如果使用的是 JPA ，甚至可以不改代码。

@hahaFck 如果设计成 user 表中加 department_id ，表示 user 对 department 有依赖，显然，业务上他们之间并不是这种关系。而且一个 user 可能会对应多个 department 。

至于你说的 organization ，和 user 不是直接关系，而是通过 department 间接关联，那么应该是 organization_department_relational 。

实体应该是独立的，不应该直接关联另一个实体，不同实体应该划分好边界，也就是 domain 的概念，通过关联表间接关联。

> user
> department
> user_department_relational

提醒作用，不使用 IDE 情况下，可以通过 override 就可以知道是重写方法。
如果父类删掉了某个方法，子类 override 修饰的方法编译时会报错。

反向操作....
正常应该是 jar 包发布后，保留对应版本的分支或者打 tag ，这样通过版本号可以找到 git history

我用 Go 也一样，有时候多提交几次就双 90% 了