| 问题 | 答案 | |
|---|---|---|
| ① | customer_owners 要不要 role | 不要 |
| ② | 客户 ↔ 人 是不是多对多 | 是 |
| ③ | 要不要 user_channels 表 | 不要 —— 但理由和 ①② 无关 |
你问「去掉 role 那还需要 user_channels 吗」—— 这两件事其实不相干,缠在一起才觉得乱。
判据很简单:现在没有任何代码会因为 role 不同而做不同的事。 PM、开发、销售,在推送这件事上待遇完全一样 —— 都是「跟这个客户的人」,都该收到。
| 加一个没人读的字段 | = 现在就欠一笔债。以后有人看到它会问「这个要不要填」,而没人答得上来 |
| 将来真要区分呢 | 那时候加一列即可,而且那时候才知道该怎么分。现在猜,大概率猜错 |
现有的 sales_owner / pm_owner / fde_owner 三个字段是 frontmatter 的历史遗留,
实际用法就是「都发」 —— 它们的区分从来没被消费过。
去掉 role 之后,这张表就剩下它本来的样子:
一个客户 N 个人,一个人 N 个客户。两个销售一起跟 = 两行;销售 + 产品 = 也是两行。 不需要额外概念。
你上一轮批的是 lark_open_id 这个列名带了 lark。那个批评是对的,
但解药不一定是建表:
| 耦合来自列名 | lark_open_id → 加 Teams 要 ALTER TABLE |
| 解耦只需要中性列名 | channel_account_id → 存什么由渠道类型决定,加 Teams 不改 schema |
那还要不要一对多?取决于一个事实:一个人会同时用两家 IM 吗。
我们是 per-box 单租户 —— 一个盒子 = 一个组织 = 一套 IM。
Sparticle 全员用 Lark;将来某个客户组织用 Teams,那是整个盒子用 Teams。
所以「人 ↔ 渠道账号」在一个盒子里就是一对一 —— 一列足够,不需要表。
| 放哪 | |
|---|---|
| 渠道类型(lark / teams) | 盒子级配置 —— 它是组织的属性,不是人的 |
| 这个人在那渠道的 id | users.channel_account_id 一列 |
⚠️ 真到了「一人多渠道」那天(比如切换期要双发),再从一列迁到一张表 —— 那是很轻的迁移,而现在建表是为一个猜出来的需求付钱。
| 改动 | |
|---|---|
users 加 2 列 | notify · channel_account_id |
customer_owners | 新表 · 纯多对多 · 两个字段 |
deliveries | 新表 · 送达台账 |
deliveries.channel 仍然保留 —— 它记的是当时实际走了哪条。
将来换渠道后,历史台账仍能说清楚那条消息是从哪发出去的。
| 版本 | 新表 | 被砍掉的原因 |
|---|---|---|
| v1 | user_channels | 我先提了 |
| v2 | (取消 user_channels) | 理由说错了(把「避免副本」说成「避免建表」) |
| v3 | user_channels + customer_owners(带 role) + deliveries | 你指出一对多不该压进列 —— 对,但我矫枉过正 |
| v4 | customer_owners + deliveries | role 没有消费方 · 渠道是组织级属性,per-user 是一对一 |
四版下来砍到最小,而每一次砍都有具体理由 —— 这个来回是值得的。