wren
369 lines
6.9 KiB
Markdown
369 lines
6.9 KiB
Markdown
# 内部公文模块数据表复用与新增建议
|
|
|
|
## 1. 结论
|
|
|
|
数据表不需要“全部重新建”，但也不建议“全部硬复用当前项目现有表”。
|
|
|
|
最合理的方式是：
|
|
|
|
- 复用当前项目已有的“平台公共表”
|
|
- 新建 `govdoc` 自己的“结果域表”
|
|
- 不要把公文模块的运行和结果强塞进现有 `leaudit` 专属结果表
|
|
|
|
一句话：
|
|
|
|
- 主档能复用
|
|
- 结果别乱复用
|
|
|
|
---
|
|
|
|
## 2. 建议直接复用的表
|
|
|
|
以下属于平台级公共能力，建议直接复用：
|
|
|
|
### 2.1 用户与权限相关
|
|
|
|
- `sso_users`
|
|
- `roles`
|
|
- `user_role`
|
|
- `permissions`
|
|
- `role_permissions`
|
|
- `sys_routes`
|
|
- `role_route`
|
|
|
|
这些负责：
|
|
|
|
- 用户身份
|
|
- JWT 登录态
|
|
- RBAC 授权
|
|
- 菜单显示
|
|
- 接口动作权限
|
|
|
|
### 2.2 文档主档相关
|
|
|
|
- `leaudit_documents`
|
|
- `leaudit_document_files`
|
|
|
|
这些负责：
|
|
|
|
- 文档主记录
|
|
- 文件版本
|
|
- 文件角色
|
|
- 所属地区
|
|
- 创建人
|
|
- OSS 路径关联
|
|
|
|
### 2.3 存储与任务基础设施
|
|
|
|
虽然不是数据表，但这些平台能力也必须复用：
|
|
|
|
- OSS / MinIO
|
|
- Celery
|
|
- 当前统一配置体系
|
|
|
|
---
|
|
|
|
## 3. 为什么文档主档可以复用
|
|
|
|
从平台视角看，公文本质上也是文档。
|
|
|
|
当前 `DocumentServiceImpl` 已经处理了很多平台公共问题：
|
|
|
|
- 上传
|
|
- 文档类型归属
|
|
- 地区归属
|
|
- 文件版本
|
|
- OSS 存储
|
|
- 创建人
|
|
- 列表查询
|
|
- 数据隔离
|
|
|
|
这说明：
|
|
|
|
- `leaudit_documents` 更像平台级文档主表
|
|
- 不只是某一个引擎专属表
|
|
|
|
所以公文模块完全可以这样接：
|
|
|
|
- 公文先入 `leaudit_documents`
|
|
- 文件入 `leaudit_document_files`
|
|
- 再通过模块标识或引擎标识决定后续执行链
|
|
|
|
---
|
|
|
|
## 4. 建议补充的主档字段
|
|
|
|
建议在 `leaudit_documents` 增加一个模块或引擎标识字段，例如：
|
|
|
|
- `engine_type`
|
|
|
|
可选值例如：
|
|
|
|
- `leaudit`
|
|
- `govdoc`
|
|
- `rag`
|
|
|
|
或者使用：
|
|
|
|
- `biz_module`
|
|
|
|
作用是让平台明确知道：
|
|
|
|
- 这份文档属于哪个处理模块
|
|
- 应走哪条执行链
|
|
- 应展示哪套结果详情页面
|
|
|
|
这个字段非常关键。
|
|
|
|
---
|
|
|
|
## 5. 不建议直接复用的现有结果表
|
|
|
|
不建议直接复用的主要是“运行结果型表”，例如：
|
|
|
|
- `leaudit_audit_runs`
|
|
- `leaudit_rule_results`
|
|
- 以及现有 `leaudit` 引擎专属的 metrics / extraction / rescue 一类结果表
|
|
|
|
原因如下。
|
|
|
|
### 5.1 字段语义会越来越脏
|
|
|
|
当前 `leaudit` 的运行结果表，天然围绕现有审查引擎设计，可能包含：
|
|
|
|
- phase
|
|
- OCR / extract / rescue 阶段
|
|
- ruleSetId / ruleVersionId
|
|
- resultStatus
|
|
- rescueApplied
|
|
- 当前引擎专属 timing / metrics
|
|
|
|
而 `govdoc` 运行时更关注：
|
|
|
|
- 公文结构解析
|
|
- 标题 / 发文字号 / 文种 / 附件识别
|
|
- 段落级 findings
|
|
- HTML / annotated docx / paragraph html 报告
|
|
|
|
表面上都叫 run，但含义并不完全相同。
|
|
|
|
### 5.2 结果明细模型不完全兼容
|
|
|
|
`govdoc-audit` 的单条 finding 更像：
|
|
|
|
- `rule_id`
|
|
- `rule_name`
|
|
- `severity`
|
|
- `category`
|
|
- `location.paragraph_index`
|
|
- `message`
|
|
- `suggestion`
|
|
- `actual`
|
|
- `expected`
|
|
- `evidence`
|
|
|
|
它非常强调：
|
|
|
|
- 段落定位
|
|
- 文档结构位置
|
|
- 格式问题
|
|
|
|
而当前 `leaudit_rule_results` 更可能偏：
|
|
|
|
- 评查点
|
|
- 提取字段
|
|
- 风险
|
|
- rescue 翻转
|
|
- 审核结果
|
|
|
|
两者不是一个结果语义世界。
|
|
|
|
### 5.3 后续统计口径容易混乱
|
|
|
|
如果共用结果表，后面做统计时会不断出现问题：
|
|
|
|
- 这个 `passed_count` 是公文规则通过数，还是合同规则通过数？
|
|
- 这个 `failed_count` 是格式错误项数，还是评查点失败数？
|
|
- 这个 `score` 的计算口径是否一致？
|
|
|
|
最终会逼着所有查询都加一层 `engine_type` 判断。
|
|
|
|
### 5.4 迁移与回滚成本更高
|
|
|
|
架构上：
|
|
|
|
- 从专属表改回公共表，容易
|
|
- 从硬复用公共表再拆出来，很痛苦
|
|
|
|
所以结果域隔离更稳。
|
|
|
|
---
|
|
|
|
## 6. 最推荐的折中方案
|
|
|
|
最佳折中不是“全新建”，也不是“全复用”，而是：
|
|
|
|
- 1 套平台主档
|
|
- 1 个模块标识字段
|
|
- 1 套 `govdoc` 结果域表
|
|
|
|
### 6.1 第一层：复用公共文档主档
|
|
|
|
继续使用：
|
|
|
|
- `leaudit_documents`
|
|
- `leaudit_document_files`
|
|
|
|
负责：
|
|
|
|
- 上传文档主记录
|
|
- 保存文件版本
|
|
- 地区归属
|
|
- 创建人
|
|
- OSS 路径
|
|
|
|
### 6.2 第二层：补充模块标识
|
|
|
|
在 `leaudit_documents` 增：
|
|
|
|
- `engine_type = 'govdoc'`
|
|
|
|
这样主档表知道：
|
|
|
|
- 这是一份由公文模块消费的文档
|
|
|
|
### 6.3 第三层：新增公文结果域表
|
|
|
|
建议新增：
|
|
|
|
- `govdoc_runs`
|
|
- `govdoc_rule_results`
|
|
- `govdoc_entities`
|
|
- `govdoc_report_artifacts`
|
|
|
|
好处：
|
|
|
|
- 上传、权限、地区、OSS 全复用
|
|
- 结果和运行态不污染原系统
|
|
- 前端查询和统计都清晰
|
|
|
|
---
|
|
|
|
## 7. 如果想极限少建表，最少也要新建哪几张
|
|
|
|
如果希望第一阶段尽量少建表，建议最少也要新建 3 张：
|
|
|
|
- `govdoc_runs`
|
|
- `govdoc_rule_results`
|
|
- `govdoc_report_artifacts`
|
|
|
|
可选第 4 张：
|
|
|
|
- `govdoc_entities`
|
|
|
|
如果想更快推进，`entities` 也可以先临时塞进 `govdoc_runs.result_json` 之类字段里，但长期仍建议拆表。
|
|
|
|
---
|
|
|
|
## 8. 什么情况下可以复用当前 `leaudit_audit_runs`
|
|
|
|
只有一种情况可以考虑：
|
|
|
|
先把 `leaudit_audit_runs` 正式重构为“平台通用引擎运行表”，明确它不再是 `leaudit` 私有运行表。
|
|
|
|
此时至少要补齐类似字段：
|
|
|
|
- `engine_type`
|
|
- `biz_module`
|
|
- `result_summary_json`
|
|
- `artifact_manifest_json`
|
|
|
|
然后让：
|
|
|
|
- `leaudit`
|
|
- `govdoc`
|
|
|
|
都成为这张“通用运行表”的消费者。
|
|
|
|
但要注意，这已经不是“直接复用原表”，而是：
|
|
|
|
- 先重构当前表
|
|
- 再让它变成通用表
|
|
|
|
这条路能走，但复杂度明显高于“新建 `govdoc_runs`”。
|
|
|
|
当前阶段，更推荐后者。
|
|
|
|
---
|
|
|
|
## 9. 明确建议
|
|
|
|
我的明确建议是：
|
|
|
|
- 不用全部重建
|
|
- 但也不要零成本硬复用全部现有结果表
|
|
|
|
最佳实践：
|
|
|
|
- 复用 `用户 / 权限 / 地区 / 文档主档 / 文件主档 / OSS / 任务系统`
|
|
- 新建 `govdoc` 的 `run + result + artifact` 结果域表
|
|
|
|
即：
|
|
|
|
**复用公共底座，新建领域结果。**
|
|
|
|
---
|
|
|
|
## 10. 推荐最终表划分
|
|
|
|
### 10.1 复用
|
|
|
|
- `sso_users`
|
|
- `roles`
|
|
- `user_role`
|
|
- `permissions`
|
|
- `role_permissions`
|
|
- `sys_routes`
|
|
- `role_route`
|
|
- `leaudit_documents`
|
|
- `leaudit_document_files`
|
|
|
|
### 10.2 建议补字段
|
|
|
|
- `leaudit_documents.engine_type`
|
|
- 或 `leaudit_documents.biz_module`
|
|
|
|
### 10.3 新增
|
|
|
|
- `govdoc_runs`
|
|
- `govdoc_rule_results`
|
|
- `govdoc_entities`
|
|
- `govdoc_report_artifacts`
|
|
|
|
后续规则平台化时再补：
|
|
|
|
- `govdoc_rule_sets`
|
|
- `govdoc_rule_versions`
|
|
|
|
---
|
|
|
|
## 11. 最终落地建议
|
|
|
|
如果现在立刻开始实施，建议按下面这版定：
|
|
|
|
1. `leaudit_documents` / `leaudit_document_files` 继续复用
|
|
2. 在 `leaudit_documents` 增加 `engine_type='govdoc'`
|
|
3. 新建 `govdoc_runs`
|
|
4. 新建 `govdoc_rule_results`
|
|
5. 新建 `govdoc_report_artifacts`
|
|
6. 后续视情况补 `govdoc_entities`
|
|
|
|
这是一版：
|
|
|
|
- 改动面适中
|
|
- 风险最小
|
|
- 迁移成本可控
|
|
- 长期仍可扩展
|
|
|
|
非常适合当前项目阶段。
|