PostgreSQL用户与徽章关系建模：表结构设计咨询

问题1：是否应合并User与Issuer表，新增角色标识字段？ #

不建议合并，核心原因如下：

• 数据冗余问题：普通用户不需要createdBadges这类Issuer专属字段，合并后会产生大量空值，违反数据库第一范式，导致表结构臃肿，后续维护成本上升。
• 业务逻辑清晰度：Issuer是User的升级角色，但两者业务属性有明确区分——Issuer具备创建徽章的能力，普通用户没有。分开存储能让表结构更贴合业务逻辑，后续修改Issuer专属字段时，不会影响基础用户表的稳定性。
• 性能实际表现：如果绝大多数用户都是普通用户，合并表会让查询User基础数据时加载不必要的字段，反而降低查询效率。若担心一对一JOIN的性能，只需给Issuer表的user_id字段加唯一索引，PostgreSQL对小表的JOIN优化已经很成熟，不会有明显性能瓶颈。

问题2：是否应创建Issuances独立表记录Badge与User的关联，还是用数组引用？ #

必须使用独立的Issuances中间表，理由如下：

• 逻辑一致性保障：中间表可通过外键约束，强制关联的user_id和badge_id必须存在于对应表中，避免数组出现无效ID、重复值等数据脏污问题。
• 可管理性优势：
  • 增删改操作更直观：给用户颁发徽章只需插入一条记录，撤销徽章只需删除对应行；用数组的话需要更新数组元素，操作繁琐且容易出错。
  • 扩展性强：后续如果需要记录徽章的颁发时间、过期时间、颁发备注等信息，直接在中间表加字段即可，数组无法支持这类扩展需求。
• 运行效率提升：
  • 复杂查询更高效：查询某个徽章的所有持有者、统计用户的徽章数量、筛选特定时间内颁发的徽章，用中间表的SQL语句更简洁，PostgreSQL查询优化器能更好地利用索引提升性能；用数组则需要unnest()函数展开，查询速度慢且难以优化。
  • 索引支持完善：可给中间表的user_id、badge_id字段单独建索引，或建联合索引，大幅提升关联查询速度；数组无法针对内部元素建立有效索引。

内容的提问来源于stack exchange，提问作者Ahmet Yazıcı