loan-pricing/docs/superpowers/specs/2026-03-31-production-db-init-export-design.md

生产初始化数据库导出设计文档

1. 背景

当前项目已经存在若依基础库脚本 sql/ry_20250522.sql，也存在历史的全量结构导出文件和“必要数据”导出文件。但本次目标不是继续导出业务数据，而是为生产部署准备一个单一、可直接执行的数据库初始化脚本。

该脚本需要满足以下要求：

• 以若依基础表和初始化数据为基线
• 在此基础上补齐贷款定价项目新增的所有业务表
• 不携带任何业务数据
• 最终导出为一个文件，生产环境可直接执行

2. 已确认约束

• 最终产物必须是一个单一 .sql 文件
• 若依基础部分直接复用 sql/ry_20250522.sql
• 不从当前数据库重新抽取 sys_* 管理数据
• 不导出任何业务数据
• 不拆分为“基础脚本 + 增量脚本”多步执行
• 不增加兼容性、补丁性或兜底性方案
• 方案必须保持最短路径实现

3. 当前资产与现状

3.1 已有基础脚本

sql/ry_20250522.sql 已包含若依基础表结构以及初始化管理数据，覆盖部门、用户、岗位、角色、菜单、字典、参数、通知、定时任务等基础能力。

3.2 已有历史导出文件

仓库内已有以下历史文件，可作为字段和表范围核对依据：

• sql/loan_pricing_schema_20260328.sql
• sql/loan_pricing_required_data_20260328.sql

其中 loan_pricing_required_data_20260328.sql 带有业务数据，不符合本次生产初始化目标，因此本次不能直接复用。

3.3 业务增量表范围

相对于若依基础脚本，当前项目新增的业务表结构只有以下 3 张：

• loan_pricing_workflow
• model_corp_output_fields
• model_retail_output_fields

本次生产初始化导出只需要将这 3 张表的最终结构追加到若依基础脚本之后。

4. 方案对比

方案一：生成单一生产初始化总脚本

做法：

• 以 sql/ry_20250522.sql 为主体
• 追加 3 张业务表的最终 DROP TABLE 与 CREATE TABLE
• 形成一个新的、可直接执行的生产初始化 SQL 文件

优点：

• 与本次“一个文件直接执行”的目标完全一致
• 路径最短，执行成本最低
• 不依赖实时连库导出，不会误带当前库中的业务数据
• 基础初始化内容与现有若依脚本保持一致，可控性高

缺点：

• 后续业务表结构变化后，需要重新生成该文件

方案二：保留若依基础脚本，再新增一个业务表增量脚本

做法：

• 保持 sql/ry_20250522.sql 不变
• 额外新增一个只包含业务表结构的 SQL 文件
• 生产执行时先跑基础脚本，再跑增量脚本

优点：

• 文件职责分离较清晰

缺点：

• 不满足“导出到一个文件内”的明确要求
• 生产执行需要多步操作
• 增加人为漏执行或执行顺序错误的风险

方案三：从当前数据库重新导出全库，再手工删除不需要的内容

做法：

• 基于当前数据库重新导出结构与数据
• 人工删除业务数据和不需要的表内容

优点：

• 理论上能快速拿到一个初稿

缺点：

• 风险最高，容易混入业务数据、运行态数据和测试数据
• 结果依赖当前库状态，不稳定
• 不符合最短路径且可控的实现要求

5. 设计结论

采用方案一：生成单一生产初始化总脚本。

最终产物是一个新的 SQL 文件，放在 sql 目录，用于生产数据库初始化。该文件以若依基础脚本为主体，追加 3 张业务表结构，不包含任何业务表数据。

6. 导出文件设计

6.1 文件职责

该文件只负责“生产数据库初始化”，不承担历史数据迁移、业务数据灌库或环境差异兼容职责。

6.2 文件内容组成

建议内容结构如下：

1. 头部说明
2. 数据库创建与切库语句
3. 若依基础表结构与初始化数据
4. 贷款定价业务表结构
5. 执行结束后的环境恢复语句

6.3 文件命名

建议命名为：

• sql/loan_pricing_prod_init_20260331.sql

命名目标是明确表达“生产初始化”用途，并带上生成日期，方便后续版本追踪。

7. 保留与排除范围

7.1 保留内容

保留内容分为两部分：

第一部分是若依基础脚本中的全部基础表与初始化数据，直接复用 sql/ry_20250522.sql 的现有内容。

第二部分是项目业务增量表结构，仅保留如下 3 张表的结构定义：

• loan_pricing_workflow
• model_corp_output_fields
• model_retail_output_fields

7.2 排除内容

以下内容明确不进入生产初始化脚本：

• loan_pricing_workflow 的任何记录数据
• model_corp_output_fields 的任何记录数据
• model_retail_output_fields 的任何记录数据
• 从当前数据库重新抽取的 sys_* 数据
• 任何日志、运行历史、流程历史、演示数据、测试数据

8. 业务表结构来源

3 张业务表的结构应以当前仓库中已经确认的最终版本为准，结构来源优先按以下顺序核定：

1. sql/loan_pricing_schema_20260328.sql 中对应表的最终结构
2. sql/loan_pricing_workflow.sql、sql/model_corp.sql、sql/model_retail.sql
3. 其后的结构修正脚本，例如字段补充、字段注释修复、执行利率字段补充等 SQL

如果存在同名表的多份定义，应以能反映当前最终字段状态的版本为准，避免把旧结构写入生产初始化脚本。

9. 生成方式

本次采用静态拼装方式生成，不依赖实时数据库导出。

生成步骤如下：

1. 复制 sql/ry_20250522.sql 的基础内容
2. 从最终结构来源中提取 3 张业务表的 DROP TABLE 与 CREATE TABLE
3. 将业务表结构追加到基础内容后方
4. 在文件头部补充脚本说明，明确用途、范围和排除项

该方式可以保证结果稳定、内容可审查，并且不会因为当前数据库状态不同而发生漂移。

10. 验证设计

本次验证只围绕“单文件是否可用于生产初始化”展开，必须覆盖以下检查：

1. 检查脚本是否为单文件，且可独立执行
2. 检查脚本中是否完整包含若依基础内容
3. 检查脚本中是否完整包含 3 张业务表结构
4. 检查脚本中业务表不存在任何 INSERT 数据语句
5. 在测试库执行脚本，验证建库建表流程可跑通
6. 导入完成后核对若依基础表存在初始化数据
7. 导入完成后核对 3 张业务表为空表

11. 风险与控制

主要风险如下：

1. 如果业务表结构来源选择错误，可能把旧字段定义带入生产脚本
2. 如果直接复用带数据的历史导出文件，可能误将业务数据带入生产
3. 如果脚本顺序错误，可能导致执行时报表不存在或环境切换错误

控制方式如下：

• 明确以若依基础脚本为唯一基础来源
• 明确业务增量仅限 3 张表结构
• 明确禁止业务表 INSERT 语句进入最终脚本
• 通过测试库执行验证最终脚本的可执行性

12. 非目标

本次不包含以下内容：

• 不迁移任何业务数据
• 不重建当前环境中的真实用户与权限现状
• 不处理生产数据回灌
• 不新增多环境兼容脚本
• 不生成多文件执行方案