leaudit-platform-backend/docs/内部公文模块/内部公文模块数据表复用与新增建议.md

内部公文模块数据表复用与新增建议

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

这是一版：

• 改动面适中
• 风险最小
• 迁移成本可控
• 长期仍可扩展

非常适合当前项目阶段。