产品数据库设计：插件独立表 vs 主表新增字段

业务场景：网站总用户 10000 人，仅 100 人拥有勋章。

• 插件模式：勋章使用独立数据表，只记录已授予勋章的用户
• 集成模式：直接在用户表增加勋章字段，绝大多数用户该字段为空

方案对比

表格

场景结论

一万用户仅 100 人获得勋章：优先选择独立子表（插件模式），不要在 user 主表堆砌勋章字段。

1. 99% 用户没有勋章，主表新增字段属于稀疏数据，浪费存储同时拖累最高频的用户表；
2. 勋章业务天然附带扩展字段：获取时间、过期时间、发放来源，简单字段很难承载；
3. 不建议使用 JSON 字段存储勋章列表：JSON 无法建立有效索引，无法快速筛选拥有某类勋章的用户。

什么时候适合直接加到 user 主表？
只有几乎全部用户都一定具备、不会为空的属性，才放入用户主表。例如：性别、注册时间。

误区：插件多了，全部集成到内核是不是更好？

不建议。插件数量越多，越要避免把插件业务字段全部堆入主用户表。

全部集成的代价：

1. user 表持续膨胀，高频核心表变得臃肿；
2. 业务强耦合，关闭功能模块无法干净剥离数据库；
3. 后期迭代 DDL 风险巨大，大表 ALTER 是线上高危操作。

设计原则

1. 稀疏业务（仅少数用户存在数据）：独立子表，插件自有数据表。 勋章、临时会员、任务记录等属于此类。
2. 全局高频、每个用户必有数据：集成进 user 主表。
3. 插件带来的成本主要是多表 JOIN 与代码分层；换取内核干净、模块可插拔、数据库性能可控。