D&D角色创建项目中SQL表用数组存储多个proficiency ID是否可行？

结论 #

技术上可以实现，但绝大多数场景下更推荐使用传统多对多关联表的方案，数组存储仅适合非常简单的小型项目使用。

数组存储方案的利弊 #

优势 #

• 实现成本低，无需额外建表，单表查询即可直接拿到角色关联的所有专长ID，前后端代码处理逻辑更直观
• 单条角色数据的插入、更新操作只需操作单表，无需处理多表写入的事务问题

劣势（核心问题） #

违反关系型数据库第一范式，单个字段存储多值会引入大量数据一致性和查询效率问题：

• 无法使用外键约束，不能保证数组中存储的ID在proficiencies表中真实存在，很容易产生脏数据
• 关联查询复杂度高，如需查询角色所有专长的具体名称，需要额外编写数组拆分逻辑，性能远低于普通JOIN查询
• 反向查询效率极低，如果需要查询「所有拥有某类专长的角色」，需要全表扫描并拆分所有数组字段，数据量稍大就会出现明显的性能瓶颈
• 大部分ORM框架对数组类型字段的支持不完善，后续业务开发容易出现适配问题

推荐方案 #

新增一张多对多关联表绑定角色和专长的关系，示例结构如下：

Table character_proficiencies {
  id int [pk]
  character_id int [fk -> characters.id]
  proficiency_id int [fk -> proficiencies.id]
}

该方案的优势：

• 符合关系型数据库设计规范，通过外键约束可以完全避免无效ID的脏数据问题
• 所有关联查询都可以通过简单JOIN实现，正反查询性能都有保障
• 扩展性强，后续如果需要给角色的专长增加额外属性（比如专长获取来源、临时生效时间等），直接在关联表新增字段即可，无需修改原有表结构

特殊场景说明 #

如果你的项目仅为课程结业作业，数据量极小、没有复杂的关联查询需求，使用数组存储也可以正常跑通业务逻辑，只是从长期可维护和规范的角度更推荐关联表方案。

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