Laravel数据库设计：如何实现工单与多类型作业单的关联存储

两种基础方案的优劣势对比 #

方案1：单表统一存储（单migration加job_sheet_type字段区分） #

仅适合临时原型验证场景，生产环境不推荐：

• 字段冗余严重：三类作业单的差异化checklist字段会大量空置，后续新增作业单类型时表字段会持续膨胀，索引查询效率会随数据量增长快速下降
• 数据校验逻辑耦合：Laravel模型的字段类型约束、表单验证规则无法针对不同作业单类型做差异化限制，极易出现跨类型的非法字段赋值问题
• 后期维护成本高：迭代过程中修改某类作业单的字段逻辑时，很容易误影响其他类型的业务，多人协作场景下风险更高

方案2：三类作业单独立表存储（各表单独关联job_id） #

适合业务形态固定、完全没有新增作业单类型的场景，存在一定扩展限制：

• 前期开发成本略高：需要编写3个独立的migration和对应模型、校验逻辑
• 全局查询效率低：需要查询某个工单下的所有作业单时，必须联合查询三张表，后续新增作业单类型时需要修改所有全局查询的逻辑

最优高扩展方案推荐：Laravel多态关联 + 主副表结构 #

这是Laravel生态下适配该场景的标准实现方案，兼顾性能和扩展性：

实现逻辑 #

1. 先创建通用job_sheets主表，存储所有作业单的公共字段，migration核心字段如下：

Schema::create('job_sheets', function (Blueprint $table) {
    $table->id();
    $table->foreignId('job_id')->constrained()->onDelete('cascade'); // 关联工单表
    $table->morphs('job_sheetable'); // 自动生成`job_sheetable_type`、`job_sheetable_id`多态字段
    $table->foreignId('engineer_id')->constrained(); // 填写工程师id，所有类型作业单通用字段
    $table->tinyInteger('status')->default(0); // 作业单审核状态，通用字段
    $table->timestamps();
});

2. 为三类作业单分别创建独立子表，仅存储对应类型独有的checklist字段，不需要冗余job_id等公共字段，例如：

• 维修类作业单建repair_job_sheets表，存维修项、配件损耗、故障原因等独有字段
• 保养类作业单建maintain_job_sheets表，存保养等级、更换耗材、下次保养时间等独有字段
• 检测类作业单建inspection_job_sheets表，存检测项、合格标准、检测结果等独有字段

3. 模型层绑定多态关联：

• 主模型JobSheet定义morphTo()关联到具体的子类作业单模型
• 各子类作业单模型（如RepairJobSheet）定义morphOne(JobSheet::class, 'job_sheetable')关联到主表
• 工单模型Job定义hasMany(JobSheet::class)，可直接拉取某个工单下的所有作业单，通过多态关联可自动获取对应类型的明细数据

方案优势 #

• 无字段冗余：每类作业单的独有字段独立存储，表结构清晰
• 扩展性极强：后续新增作业单类型时，仅需新增对应子表和模型，不需要修改原有表结构和线上业务逻辑
• 业务逻辑解耦：每类作业单的校验规则、业务逻辑都可以在对应子类模型中独立编写，完全不影响其他类型的作业单
• 查询效率可控：需要拉取工单下所有作业单的公共信息（如提交人、审核状态）直接查主表即可，需要查看明细时再走对应子表查询，索引也可以针对不同表单独优化

特殊场景适配 #

如果三类作业单90%以上的字段完全一致，仅存在2-3个差异化字段，且确认未来不会新增作业单类型，也可以选择单表方案，但是需要在模型层做字段过滤：通过Laravel模型的动态$fillable、查询作用域针对不同job_sheet_type做字段限制，避免非法数据写入。

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