# 内部公文模块数据表复用与新增建议 ## 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` 这是一版： - 改动面适中 - 风险最小 - 迁移成本可控 - 长期仍可扩展 非常适合当前项目阶段。