不敢

我也卖一个 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% 了

涨幅不高就不要跳，继续找找。
工资不发就走仲裁，不可能输。

树高会影响 IO 次数，用 B+Tree 树就是这个原因，比 B-Tree 更矮更胖。

数据页是从磁盘加载到内存中的，如果发现数据不在当前页，可能在下一页，才会去磁盘继续加载页。

如果我是新人，我希望 mentor 做点实际的事情，而不是给我人生建议或聊一些有的没的：
0. 给我一份文档，让我在本地把环境搭建起来。（ Go/Java/Python/IDE 等等）
1. 给我开通各种权限，说明注意事项。（ Git 仓库 /DevOps/测试库 /日志等等）
2. 给我需求文档和代码仓库，让我在本地先能运行项目，然后熟悉项目需求，熟悉代码提交规范。
3. 给我介绍公司常用技术栈，让我平时能够自己学习技术。
4. 带我参与需求评审，分给我一个模块，按项目组规范写设计方案和画图。
5. 参与我的技术评审，指出我方案中的问题，给出建议。
6. 参与设计稿 /测试用例 /前端评审，介绍需要对接的同事。
7. 按集团规范进行开发，帮我 review 代码，有问题的地方及时修改。
8. 与前端同事进行联调。
9. 带我熟悉 test/QA 测试流程，如何冒烟自测，如何发提测邮件，如何使用 JIRA/禅道 等，与测试同事沟通。
10. 带我熟悉 uat/pre/prod 发布流程，如何排查问题，如何提交 SQL 脚本，一些注意事项。

带新人是上面安排的工作，做好自己的工作就行，又不是带崽。新人遇到问题时你再教他，你要让他知道“遇到问题及时问”，而不是手把手教他，更不能让他自己憋着。

如果一段时间下来，他还是无法胜任工作，问心无愧解除合同。

当然，如果新人很尊敬你，那就是另一回事了。

管理是一篇文章一本书就能学会的吗？不应该去关注员工本人吗？

美名其曰培养员工，扪心自问一下，真的投入时间和精力了吗？发现每个员工优点和缺点吗？员工产出超出预期时有给奖励吗？员工犯错的时候一起承担责任了还是甩锅了？

大部分 leader 为了方便管理，就定了一堆规矩，让员工按着自己的方向发展，甚至让员工相互卷，自己却不愿意做出一丝丝改变，这根本不是管理，所以也别指望员工能真正的尊重你，尊重是相互的，不骂你就不错了。把平台当做自己的能力，出了公司啥都不是。

按我的理解，你只能在 xml 里判断 title 是否为 null 。因为 title 为 null 时，直接用 `where article.title like #{dto.title}` 肯定是有问题的。
mybatis 就是用于动态 SQL 的场景，而且，这个判断跟业务流程也没太大关系，只是说 title 字段是 ignorable 的，在注释中写清楚就行。

搭一个 sonar 扫描代码呗，配置一下规范，分数低于 90 分不允许发布

我买的无刻的，刚开始也不太习惯，用多了就好了。不喜欢用机械键盘写代码，怕吵到别人，写久了手酸。薄膜键盘和 macbook 自带的手感就更差了。
其实主要是有洁癖，不想让别人碰我的键盘，甚至领导看我的眼神都不一样了。
https://www.v2ex.com/i/21nO1NV3.jpeg

@awanganddong

我之前也做过类似的需求，基本思路差不多，对搜索接口做了一点优化：

1. 异步删除帖子：用户被封禁时，通过 MQ 发送一条包含用户 ID 的消息，然后消费者异步删除 es 中的 docs
2. 搜索接口优化：搜索到结果后，可能存在某一个帖子还没来得及删，所以需要判断用户是否被封禁（可以通过查数据库、查用户缓存、bitmap 等方式）。如果用户被封禁，将该帖子数据简化，并标记为已封禁，然后返回给客户端。让客户端展示一个被封禁的文案（也可以直接过滤掉该条帖子，看具体需求）

由于 es 的 doc 是不可变的，所以最好不要做更新处理。更新操作实际上是通过一个.del 文件将原来的 doc 标记为逻辑删除，然后再新建一个 doc 。

真是令人唏嘘