高校学生证明申请系统MySQL库表结构合理性评估及优化咨询

• 优势：完全符合关系型数据库第三范式，无数据冗余，不同证明类型的字段约束清晰，新增证明类型仅需新增对应明细表，写入逻辑复杂度低，适合证明类型数量少、单类型查询需求远多于全类型批量查询的场景
• 劣势：全类型联合查询需要动态关联多张明细表，无法通过单条SQL拉取完整数据，Laravel中如果直接用关联查询需要定义N个一对一关联，查询列表时容易出现N+1问题，且列表页展示不同类型的独有字段时需要做额外的逻辑判断，维护成本随证明类型增加线性上升

以下方案适配不同的业务迭代需求，可根据实际情况选择：

方案1：保持现有结构，基于Laravel多态关联优化查询 #

改动最小，适合证明类型不超过5种、短期内不会大量新增类型的场景

• 可直接通过letter_type字段映射对应明细表模型，给Letter模型定义多态关联：

public function letterable()
{
    return $this->morphTo(__FUNCTION__, 'letter_type', 'id');
}

• 各个明细表对应的模型（比如ActiveStudent、ResearchPermit）定义反向关联：

public function letter()
{
    return $this->belongsTo(Letter::class, 'letter_id');
}

• 查询学生全量申请时直接用with('letterable')预加载即可，Laravel会自动完成对应表的关联查询，不需要手动编写join逻辑

方案2：单表宽表+JSON字段存储独有属性 #

适合证明类型不固定、会频繁新增类型，且独有字段不需要作为查询条件的场景

• 移除所有类型专属明细表，在letters表新增extra字段，类型设为JSON
• 不同类型的独有字段序列化后存入extra字段，Laravel中可以给模型配置$casts自动完成JSON和数组的转换：

protected $casts = [
    'extra' => 'array',
];

• 优势：查询全量申请单表就可以搞定，不需要任何关联，新增证明类型不需要改动表结构，仅需要前端和验证逻辑适配即可
• 劣势：JSON字段无法直接加索引，如果需要按独有字段检索（比如按科研标题查申请）的话性能会很差，也无法做数据库层面的字段非空、类型约束，数据校验完全要靠业务代码实现

方案3：元数据建模，通用字段+扩展属性表 #

适合证明类型多、且独有字段需要作为查询条件的中大型系统

• 保留letter_type、letters基础表
• 新增letter_meta表，字段为：id、letter_id、meta_key、meta_value，用来存储所有类型的独有属性
• 新增letter_type_meta表，字段为：type_id、meta_key、is_required、data_type，用来定义每个证明类型需要填写的扩展字段规则
• 优势：新增证明类型完全不需要改表结构，仅需要在letter_type_meta配置对应字段规则即可，支持给meta_key和meta_value加索引满足检索需求
• 劣势：写入时需要批量插入多条meta数据，查询单个申请的完整数据需要关联letter_meta表，查询多条数据时需要做行转列处理，代码复杂度比前两个方案高

• 如果学校证明类型就固定在读证明、科研许可等少数几种，优先选方案1，改动最小，现有逻辑不需要重构，仅需要加个多态关联就能解决查询复杂度的问题
• 如果后续要加很多种证明类型，且不需要按独有字段检索，选方案2最省事
• 如果系统要长期迭代，后续会有各种复杂查询需求，选方案3扩展性最好

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