MySQL权限校验场景下授权表结构设计方案选择咨询

核心结论 #

优先选择方案2，该方案完全匹配当前业务需求，开发、维护成本远低于方案1，数据一致性也更有保障。

方案2优势 #

• 完全符合数据库设计规范，无NULL值，避免三值逻辑带来的查询、校验隐患，所有主键约束天然生效，不会出现重复授权问题：
  • 整班授权表的Teacher+Class联合主键可以直接避免同一教师重复获取同一班级整班权限
  • 单学生授权表的Teacher+Class+Student联合主键可以直接避免同一教师重复获取同一学生的特殊权限
• 权限校验逻辑清晰简单，不容易出bug：校验时先查整班授权表，存在匹配记录直接放行；不存在再查单学生授权表，存在匹配记录再放行，两层逻辑独立无耦合
• 改造成本极低，向后兼容性好：原有整班授权的数据无需迁移，原有访问整班授权的业务代码完全不用修改，仅需要新增单学生授权的相关逻辑即可
• 查询性能更优：两张表的数据量可控，联合索引命中率高，无需处理NULL值相关的条件判断，查询效率更高

方案1的固有缺陷 #

• 存在NULL值，所有涉及授权表的查询、校验逻辑都需要额外处理Student IS NULL的分支，非常容易漏写条件导致权限校验错误
• 数据一致性难以保障：绝大多数主流数据库中NULL值不参与唯一约束校验，就算新增Teacher+Class+Student的唯一索引，也无法避免插入多条(Chris, Class1, NULL)的重复整班授权记录，必须额外开发业务逻辑做重复校验，大幅提升开发成本
• 原有业务逻辑需要全部改造：之前基于原授权表开发的整班权限查询、校验代码都需要新增NULL值判断，兼容成本高，容易出现线上故障

补充说明 #

如果后续业务没有新增更细粒度权限（比如按学科、按成绩类型授权）的需求，方案2完全可以支撑长期使用；如果后续有更复杂的权限诉求，可以再基于RBAC模型做统一升级。

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