railwaysystem/RuoYi-Vue/sql/train/v2/rollback

RailwaySystem 数据库 V2 应急回滚指南 (Round 1 修订版)

技术基线：KingbaseES V009R003C018 (schema=public)
回滚目标：安全撤销 V2 数据库结构变更，将数据模型与物理约束 100% 精确还原至 Phase 0.5 历史基线。

---

1. 核心架构升级：解耦结构与数据

在 Round 1 审查中，彻底废除了使用 CREATE TABLE ... AS SELECT * FROM bak_v1_*（CTAS）推断历史结构的危险方案：

┌─────────────────────────────────────────────────────────┐
│ Phase 0.5 精确物理结构 (表定义/列类型/PK/FK/UNIQUE/触发器) │
│ 来源: rollback/000_phase05_exact_schema.sql             │
└───────────────────────────┬─────────────────────────────┘
                            │ (先精确重建物理表结构)
                            ▼
┌─────────────────────────────────────────────────────────┐
│ Phase 0.5 真实数据 (唯一教师行 + 各表数据)               │
│ 来源: 001 备份生成的 bak_v1_* 快照表                    │
└───────────────────────────┬─────────────────────────────┘
                            │ (再通过 INSERT INTO 导入数据)
                            ▼
                    【Phase 0.5 绝对还原】

• 000_phase05_exact_schema.sql：作为唯一的物理结构基准，确保回滚后恢复所有 24 个旧外键、7 组旧业务唯一约束、NOT NULL、DEFAULT、IDENTITY 序列以及 9 个 update_time 触发器；
• bak_v1_* 快照表：仅承担纯粹的“数据暂存”职责。

---

2. 回滚脚本执行顺序

若在测试迁移或灰度验证阶段发现重大异常，需按照以下严格顺序执行回滚流水线：

步骤 1: 执行 001_rollback_new_tables.sql
        -> 显式解除外键依赖，安全下线并 DROP 掉 V2 新增的 8 张业务表

步骤 2: 执行 002_rollback_modified_tables.sql
        -> 基于 000_phase05_exact_schema.sql 的精确结构重建 13 张表，并从 bak_v1_* 物理快照还原数据，严格断言教师数据为 1 行

步骤 3: 执行 003_restore_legacy_score.sql
        -> 基于 000_phase05_exact_schema.sql 的精确结构重建 train_score_info 及 3 个历史外键与唯一约束

步骤 4: 人工核验 Phase 0.5 状态
        -> 执行 000_preflight.sql 校验基线恢复，确认 14 张表、触发器与约束 100% 吻合

---

3. 强前置依赖与数据来源声明

Caution

回滚操作必须满足以下前置条件：

1. 依赖 001 备份快照：
   • 步骤 2 与步骤 3 的数据还原依赖迁移前由 001_backup_current_schema.sql 生成的 bak_v1_* 快照表。
   • 若 bak_v1_* 表意外被删，严禁盲目执行数据还原语句。
2. 唯一教师数据的物理还原：
   • 教师主档 train_teacher 的数据通过 INSERT INTO train_teacher SELECT * FROM bak_v1_train_teacher; 完整回灌。回滚脚本会严格校验恢复后的教师行数必须等于 1。
3. 事务安全性：
   • 每一个回滚 SQL 文件内部均由显式 BEGIN ... COMMIT 包裹，出现任何错误自动整单回滚，不产生中间半回滚状态。

---

4. 必须人工介入确认的场景

场景 A：V2 阶段已产生新业务数据

如果系统在执行 V2 DDL 之后，业务端或测试端已经在 train_enrollment、train_lesson、train_student_score 等表中写入了新数据：

• 直接执行回滚将导致这些新业务数据彻底物理清除！
• 必须人工介入：先通过数据导出工具将 V2 新增业务数据导出为 CSV/JSON 归档，确认业务无异议后方可执行回滚。

场景 B：bak_v1_* 备份表意外缺失

若 bak_v1_* 表不存在：

• 必须暂停脚本执行；
• 从数据库物理备份集（如 sys_backup / 逻辑转储快照）中恢复 14 张旧表数据。

---

5. 回滚后验收确认 Checklist

回滚完成后，在数据库客户端中直接运行 000_preflight.sql 即可自动化完成全量反向验收：

• 1. 运行 000_preflight.sql 成功输出 [Preflight-PASS]；
• 2. 确认已无任何 V2 独有表（如 train_plan_course 等）；
• 3. 确认旧表 train_score_info 已恢复，且具备旧外键；
• 4. 确认 train_teacher 精确包含 1 条数据，且旧字段 t_department 存在且非空；
• 5. 确认 9 个旧触发器全部重新挂载生效；
• 6. 确认系统表 sys_* 完好无损。