数据库设计：应关联owners和users两张表，还是合并为一张表？

你提到的通过邮箱匹配关联的方案不是最优解，存在数据一致性和查询效率的问题，更推荐以下设计方案：

核心设计逻辑 #

保留owners、users两张独立表，通过外键关联而非邮箱字段匹配，完全适配你的业务规则：

• owners表用于存储全量owner数据，无论对应人员是否注册都永久留存
• 在users表中新增owner_id字段，作为外键关联owners表的主键ID，字段允许为空（适配后续可能存在的非owner用户注册需求）；如果你的业务要求仅owner可注册，可将该字段设为非空且唯一

为什么不推荐用邮箱匹配 #

邮箱属于可变业务字段，一旦出现owner邮箱修改、用户账号邮箱修改的情况，关联关系会直接断裂，后续数据排查修复成本极高；同时字符串字段匹配的查询效率远低于整型主键的外键关联，数据量越大性能差异越明显

配套业务逻辑 #

1. 用户注册逻辑：
   用户提交注册信息时，先校验提交的邮箱是否存在于owners表中

• 存在匹配记录：生成users表记录的同时，将owner_id字段绑定为对应owner记录的主键ID
• 无匹配记录：可根据业务规则选择拒绝注册（仅开放owner注册权限），或生成owner_id为空的用户记录（兼容非owner用户场景）

2. 权限与接口逻辑：
   API token、角色、权限配置全部存储在users表或关联的user_tokens、user_roles表中，和owners表完全解耦，避免未注册的owner占用权限相关存储资源
   接口鉴权时先校验请求携带的token，拿到对应用户的owner_id后，再查询owners表及关联业务数据返回即可
   如果你当前的业务规则已经明确要求owner和用户的邮箱终身不可修改，也可以临时使用邮箱匹配的方案，但长期迭代还是更推荐外键关联的设计。

内容的提问来源于stack exchange，提问作者Shaquan Kelly