生产实验室测试数据库设计：如何存储Work实际使用的Procedure字段？

嘿，针对你提到的实验室生产测试数据库里的这两种例外情况，我给你梳理几个实用的存储方案，都是贴合实验室合规和追溯需求来设计的：

一、处理「覆盖（Overrides）」场景：保留标准，精准记录差异 #

咱实验室的测试大多遵循标准Procedure，但偶尔会调整个别参数，这种情况千万别直接修改原Procedure或者新建一条重复的记录——既不利于追溯标准流程，也不符合审计要求。推荐这么做：

• 新建一张procedure_overrides表，专门存每个Work对标准Procedure的修改细节，字段可以这么设：

  • work_id：关联对应的Work记录（外键）
  • procedure_field：被修改的具体字段名（比如test_duration、reagent_concentration）
  • original_value：标准Procedure里的原始值（留着做对比和审计）
  • override_value：实际执行时用的修改后的值
  • override_reason：必填的修改原因（比如“样品含水率超标需延长烘干时间”，实验室合规必备）
  • created_at、created_by：记录修改时间和操作人员，方便追溯责任人

• 使用逻辑：查询某个Work的实际执行流程时，先拉取它关联的标准Procedure，再用procedure_overrides里的记录覆盖对应字段。这样既保留了标准流程的完整性，又精准记录了每一处修改。

二、处理「特殊测试」场景：两种方案按需选 #

特殊测试要么是完全不按现有流程走，要么是自定义的全新测试，这里分两种情况给你方案：

方案1：给原Procedure表加自定义标记（适合字段结构和标准流程接近的特殊测试） #

• 在procedures表中加一个is_custom布尔字段，标记这条记录是不是自定义的特殊测试流程。
• 遇到特殊测试时，新建一条is_custom = true的Procedure记录，把实际执行的所有字段值填进去，再让Work关联这条记录。
• 额外加个custom_note字段，写清楚这个特殊测试的背景（比如“客户定制的食品添加剂专项检测”），方便后续查找和理解。

方案2：独立建特殊测试表（适合字段结构和标准流程差异大的情况） #

• 如果特殊测试需要的字段和标准Procedure完全不一样，别硬塞到原表里，新建一张special_tests表，专门存特殊测试的所有字段。
• 然后在works表中加两个字段：work_type（枚举值：standard/special），以及special_test_id（外键关联special_tests）。注意procedure_id和special_test_id要互斥——当work_type是standard时用procedure_id，是special时用special_test_id。

三、额外小技巧：用视图统一查询 #

不管是覆盖还是特殊测试，业务系统查询的时候可能不想分情况处理，这时候可以建一个work_actual_procedure视图：

• 对于标准Work：先取关联的Procedure字段，再用procedure_overrides的记录覆盖对应值；
• 对于特殊测试Work：直接拉取自定义Procedure或special_tests的字段。
• 这样系统查这个视图就能拿到每个Work完整的实际执行流程，不用写复杂的分支逻辑。

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