数据库设计疑问：应创建3个药品字段还是建立一对多关系？

方案1：在query表中新增3个独立药品字段（如medicine_1、medicine_2、medicine_3） #

优势 #

• 开发成本低：无需额外建表，CRUD操作全在单表完成，和前端表单字段直接对应，落地速度快
• 查询性能好：不用关联其他表，单表查询效率更高，适配小数据量场景
• 结构直观：和当前前端最多3项的限制完全匹配，理解和维护门槛低

劣势 #

• 扩展性极差：如果后续前端允许的药品数量增加（比如从3改到5），必须修改表结构新增字段，改动成本高
• 易产生冗余：如果药品需要存储剂量、用法等附加信息，就得对应新增medicine_1_dosage、medicine_2_usage这类重复字段，导致表结构臃肿
• 不支持复杂统计：比如要统计某款药品被多少query使用，单表多字段的结构会让这类查询变得非常繁琐

方案2：新建medicines表，与query表建立一对多关联 #

优势 #

• 扩展性拉满：不管后续前端允许新增多少项药品，都不用改表结构，直接在medicines表新增关联记录即可
• 结构规范：符合数据库第三范式，避免数据冗余——药品的附加属性（剂量、规格等）只需在medicines表维护一次
• 支持复杂业务需求：比如批量更新某类药品信息、统计药品使用频次等，这类操作在关联表结构下会非常顺畅
• 长期维护成本低：清晰的表结构更便于后续迭代和团队协作

劣势 #

• 初期开发稍复杂：需要处理关联表的增删改查，查询时要做JOIN操作，比单表多一层逻辑
• 对于当前仅3项的场景，看起来有点“过度设计”

选型结论 #

• 若能明确未来不会扩展药品数量，且药品仅需存储名称这类简单信息，选方案1，快速落地即可
• 若不确定需求是否会变化，或药品需要存储更多属性，或后续有统计分析需求，优先选方案2——初期的一点开发成本，能为长期业务迭代扫清障碍

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