# 数据库初始化与配置导出维护规则

## 规则

- 全库初始化只用**一份合并脚本**：`docs/sql/config_export_all_<日期>.sql`（建结构 + 补配置 + 补身份一次性完成）。
- **任何业务/配置表结构、配置数据、系统身份/权限数据有变更**，都只重新生成这一份文件，保证其始终是最新可一键执行的版本。
- 只维护合并文件；`config_export_<日期>.sql`、`test_identity_seed_<日期>.sql` 只是生成它的中间体，不再单独提交维护。
- 违反视为遗漏：新库初始化出来缺表 / 缺菜单 / 登不上，属于未按本规则同步。

## 数据库环境

| 库 | 角色 | 说明 |
|------|------|------|
| `ruoyi-vue-pro` | **源库 / 运行库 / 权威** | dev/test/jhhg/yzfx 等配置指向它；运行后端（48080）读取；系统身份 / 权限 / 菜单的权威数据源。生成合并脚本时的数据来源。 |
| `test`（或其它空库） | **初始化目标** | 本地 application-local 等指向的空白库；执行合并脚本在此建结构 + 补配置 + 补身份。 |
| 其他 | 拷贝 | 与源库同结构同名拷贝，不参与本工作流。 |

> 生成/执行合并脚本需在**同时存在 `ruoyi-vue-pro` 与目标库的同一 MySQL 实例**上执行（阶段二用跨库 `INSERT..SELECT`）。库名含 `-` 时 SQL 里要加反引号（如 `` `ruoyi-vue-pro` ``）。

## 唯一维护文件

**`docs/sql/config_export_all_20260904.sql`**（11249 行，合并版），内部两个阶段：

| 阶段 | 内容 | 数据来源 |
|------|------|----------|
| 阶段一（原 config_export） | 全库 413 张表 `CREATE TABLE` + 6 类配置数据：①协同审批流程（act_*/bpm 激活流程元数据+定义）②协同业务配置（bpm 附件/分类/表单/用户组/监听/表达式）③BI 大屏/go-view ④MES 编码规则 ⑤系统配置主数据（system_dict_type/data、tenant、company_config）⑥AI/基础设施配置。**刻意排除身份(users)/菜单/日志/流水**。 | ruoyi-vue-pro 字面量导出（自包含） |
| 阶段二（原 test_identity_seed，已扩展为完整身份/权限） | 补导全部有效身份 + 菜单 + 权限：①`system_menu` 全部有效菜单 ②`system_dept`/`post`（仅 deleted=0）③`system_role` 全部有效角色（含 super_admin）④`system_users` 全部未删除账号（含 admin）⑤`system_user_role`（按已拷贝用户交集）⑥`system_role_menu`（按已拷贝用户所属角色交集，普通角色登录依赖）⑦`system_oauth2_client`。幂等：先 `DELETE` 再 `INSERT`。 | ruoyi-vue-pro 跨库 `INSERT..SELECT` |

日常初始化：只需在目标空库执行 `config_export_all_20260904.sql` 这一份。

## 各变更归属阶段（先判断"该放哪段"）

| 数据类别 | 放进合并文件的哪个阶段 |
|----------|-----------|
| 新业务表结构（全库任意 CREATE TABLE） | 阶段一（结构） |
| 新增/改动的配置类数据（字典、BPM 表单/流程、编码规则、BI、AI、公司配置等） | 阶段一（数据） |
| 菜单 / 部门 / 岗位 / 角色 / 用户 / 用户角色 / OAuth2 客户端 | **阶段二**（不进阶段一） |
| 业务主数据 / 单据 / 流水（物料、工单、检验单等运行数据） | 都不进（仅建空结构）；业务数据由各自迁移脚本负责 |

## 维护清单（有变更时按序执行）

1. 判断变更属于"表结构 / 配置数据"还是"身份 / 权限"，确定它应落在阶段一还是阶段二。
2. **重新生成合并文件** `config_export_all_<日期>.sql`（用当天日期命名新版本，旧版保留备查）：
   - 阶段一：从 `ruoyi-vue-pro` 导出全库结构 + 6 类配置数据。
   - 阶段二：更新身份/菜单/OAuth2 补导段（如加新菜单、新默认角色）。
   - 将两段内容按「阶段一 → 分隔注释阶段二 → 阶段二」拼接成一份完整文件。
3. 全库结构变化后，核对 Mapper/DO 是否与表结构一致（`mvn compile -q` 不受表结构影响，但需人工核对）。

## 关键约束与坑（避免踩）

- ⚠ 阶段一含**全库 `DROP TABLE IF EXISTS`**，会清空非其建表的所有表数据，**只能在全新/可覆盖空库执行**，禁止在运行库直接跑。
- ⚠ 超管 `super_admin` 登录后由代码**直接返回全部菜单**；普通角色登录则依赖 `system_role_menu`。阶段二现按已拷贝用户所属角色补导 `system_role_menu`，普通角色亦可正常登录。
- ⚠ 登录/刷新令牌**必须**有 `system_oauth2_client` 中 `client_id='default'` 的记录，否则 `validOAuthClientFromCache` 报错登不上。
- 字典 `system_dict_type`/`system_dict_data` 由阶段一导入，阶段二不重复处理。
- 源库 `system_dept`/`system_post` 含较多软删除行，阶段二仅拷贝 `deleted=0` 的有效行。
- 阶段一自包含（字面量 INSERT），不依赖源库在线；阶段二依赖源库在线做跨库拷贝。