10 KiB
10 KiB
结果总览员工结果表设计文档
模块: 初核项目详情 - 结果总览 日期: 2026-03-20 状态: 已确认
一、背景
当前结果总览页已接通的查询包括：
- 风险仪表盘
- 风险人员总览
- 模型预警次数统计
- 命中模型涉及人员
现状中，这些查询依赖 ccdi_bank_statement_tag_result、ccdi_bank_statement、ccdi_base_staff、ccdi_staff_fmy_relation 的运行时连表归并与聚合。页面访问时会重复执行重 SQL，导致响应时间偏长，尤其是模型区和风险人员总览区块。
本轮目标是新增一张结果总览结果表，把“项目内每个员工的模型触发情况”预先沉淀下来，再基于该表编写页面查询 SQL，避免结果总览页面运行时直接连回源表。
二、目标
本次设计目标如下：
- 新增一张结果总览员工结果表，记录项目内每个员工的结果快照。
- 员工亲属的流水异常命中需归并计入该员工本人。
- 页面查询只依赖项目表和结果总览员工结果表，不再运行时连
标签结果表 + 流水表 + 员工表 + 亲属表。 - 命中结果写库成功后，在同一事务内按项目整块重算结果总览员工结果表。
- 保持当前页面统计口径不变，尤其是模型卡片
warningCount仍定义为原始标签命中次数。
三、范围
3.1 本次范围
- 设计结果总览员工结果表结构
- 设计员工本人和亲属命中的归并口径
- 设计命中结果写库后的同步重算链路
- 设计结果总览 4 类查询从结果表取数的方案
- 后续输出前后端实施计划与实施记录
3.2 不在本次范围
- 不覆盖结果总览风险明细区块
- 不引入异步刷新、缓存或消息队列
- 不做增量更新，只做按项目整块重算
- 不新增多张平行结果表
- 不保留中高风险 TOP10 区块及其专用查询设计
四、当前口径约束
本次设计确认以下业务口径：
- 结果表粒度为
项目 + 员工，一行代表一个项目内一个归并后的员工结果。 - 员工亲属的流水异常命中，必须归并到对应员工本人名下。
- 命中结果写库成功后，结果表需要在同一事务内同步重算完成。
- 重算方式采用“按项目整块重算当前已接通区块所需数据”。
- 模型卡片中的
warningCount定义保持现状，为原始标签命中次数，而不是员工人数或规则去重数。
五、方案对比
5.1 方案 A：直接存页面结果快照
做法：
- 按项目保存仪表盘、风险人员总览、模型卡片、模型人员列表等页面结果快照
问题：
命中模型涉及人员存在ANY / ALL / keyword / deptId / pageNum等动态筛选- 一旦直接存页面结果，筛选和分页要么退化为内存处理，要么继续依赖复杂 JSON 查询
- 无法满足“先保存员工触发情况，再根据结果表写 SQL”的要求
5.2 方案 B：单表保存项目内每个员工的结果快照
做法：
- 新增一张结果总览员工结果表
- 以
project_id + staff_id_card为唯一口径 - 每行保存员工基础信息、风险统计、模型命中快照、规则命中快照
- 页面查询全部基于该表聚合或筛选
优点：
- 符合“先存员工触发情况，再写页面 SQL”的要求
- 页面查询可以收敛为单表查询
- 兼容
ANY / ALL、关键字、部门、分页等动态筛选 - 与当前统计口径兼容，不需要改业务定义
缺点：
- 命中结果写库后需要按项目整块重算该表
- 表中会存在部分汇总冗余字段和 JSON 快照字段
5.3 方案 C：多张专用结果表
做法：
- 仪表盘、风险人员、模型卡片、模型人员分别建独立结果表
问题：
- 不符合本轮“创建一张结果总览结果表”的目标
- 数据维护面更大，DDL 和重算逻辑更分散
5.4 推荐方案
采用方案 B：新增一张“结果总览员工结果表”，以员工为核心粒度预聚合，再由页面查询基于该表出数。
六、结果表设计
建议表名：
ccdi_project_overview_employee_result
建议主键与唯一性约束：
- 主键：
id - 唯一键：
uk_project_staff (project_id, staff_id_card)
建议字段如下。
6.1 基础标识字段
project_idstaff_id_cardstaff_idstaff_namestaff_codedept_iddept_name
6.2 风险统计字段
rule_count- 该员工命中的规则数，按
rule_code去重
- 该员工命中的规则数，按
model_count- 该员工命中的模型数，按
model_code去重
- 该员工命中的模型数，按
hit_count- 该员工归并后的原始标签命中总次数
risk_level_code- 依据现有规则推导
HIGH / MEDIUM / LOW
- 依据现有规则推导
top_rule_codetop_rule_namerisk_point- 按命中次数降序、规则编码升序拼接规则名
6.3 模型与规则快照字段
model_codes_csv- 员工命中的全部模型编码，逗号分隔，统一按编码排序
model_names_json- 员工命中的模型名称数组
hit_rules_json- 员工命中的规则数组，元素建议至少包含：
ruleCoderuleNameriskLevelmodelCodemodelNamehitCount
- 员工命中的规则数组，元素建议至少包含：
model_hit_summary_json- 员工按模型汇总的数组，元素建议至少包含：
modelCodemodelNamewarningCountruleCounthitRuleList
- 员工按模型汇总的数组，元素建议至少包含：
其中：
warningCount表示该员工在该模型下的原始标签命中次数hitRuleList用于页面“异常标签”展示
6.4 审计字段
create_bycreate_timeupdate_byupdate_time
七、员工归并与重算链路
7.1 归并口径
员工结果重算时，继续沿用当前结果总览链路中的归并规则：
- 员工本人命中，归并到本人。
- 当命中对象为空或为亲属对象时，通过流水身份证号或亲属身份证号映射到员工本人。
- 无法归并到员工本人的命中记录，不进入结果总览员工结果表。
本轮不调整归并逻辑，只把这一步从页面查询阶段前移到结果表重算阶段。
7.2 重算触发时机
触发点放在命中结果写库成功之后、事务提交之前。
触发顺序固定为：
- 写入当前项目标签结果
- 删除当前项目历史员工结果
- 基于当前项目全量标签结果，按员工归并口径重算员工结果
- 批量插入新的员工结果
- 同事务刷新项目表中的高/中/低风险人数
- 提交事务
7.3 重算方式
本次采用按项目整块重算，不做增量更新。
原因：
- 需求已明确接受按项目整块重算
- 这样实现路径最短，且避免增量口径漂移
- 同事务内先删后插更容易保证一致性
八、页面查询改造方案
改造后，结果总览页查询只依赖：
ccdi_projectccdi_project_overview_employee_result
8.1 风险仪表盘
来源：
ccdi_project.target_count- 员工结果表按
risk_level_code的人数统计
查询方式：
- 高风险人数：结果表中
risk_level_code = 'HIGH' - 中风险人数：结果表中
risk_level_code = 'MEDIUM' - 低风险人数：结果表中
risk_level_code = 'LOW' - 无风险人数：
target_count - high - medium - low
8.2 风险人员总览
来源：
- 员工结果表单表查询
返回字段：
staff_namestaff_id_carddept_namehit_countrisk_level_codemodel_countrisk_point
排序延续现有口径：
- 风险等级
- 模型数
- 规则数
- 员工身份证号
8.3 模型预警次数统计
来源：
- 员工结果表中的
model_hit_summary_json
查询逻辑：
- 先按项目过滤员工结果表
- 展开每位员工的模型汇总
- 按
modelCode聚合
统计口径：
warningCount= 各员工该模型warningCount求和peopleCount= 命中该模型的员工人数
排序口径：
warningCount descmodel_code asc
8.4 命中模型涉及人员
来源：
- 员工结果表中的
model_codes_csv model_names_jsonhit_rules_jsonmodel_hit_summary_json
筛选规则：
keyword：匹配员工姓名或工号deptId：精确匹配部门modelCodes：ANY：命中任一所选模型即可ALL：必须同时命中全部所选模型
实现建议：
ANY / ALL筛选优先基于model_codes_csvmodelNames和hitTagList展示基于 JSON 快照组装
这样可以把：
- 结构化筛选
- 模型条件判断
- 分页排序
都控制在结果表层完成，避免回源连表。
九、索引建议
为保证页面查询稳定，建议增加如下索引：
- 唯一键：
(project_id, staff_id_card) - 普通索引：
(project_id, risk_level_code) - 普通索引：
(project_id, dept_id) - 普通索引：
(project_id, staff_name) - 普通索引：
(project_id, staff_code)
本轮先不扩展模型专用索引，优先依赖整项目重算后的结果表降本。如果后续 model_codes_csv 筛选成为瓶颈，再评估是否引入模型筛选辅助列。
十、测试与验收口径
本次设计的验收以“结果表口径与当前业务口径一致”为准，重点验证：
- 同一项目下，结果表员工数应等于当前可归并出的员工数。
- 员工亲属的流水异常命中必须归并到员工本人。
- 风险仪表盘的高/中/低人数与结果表按等级统计一致。
- 风险人员总览展示字段与结果表字段映射一致。
- 模型卡片
warningCount必须等于原始标签命中次数汇总。 - 模型卡片
peopleCount必须等于命中该模型的员工人数。 - 命中模型涉及人员在
ANY / ALL / keyword / deptId条件下的结果，必须与旧逻辑一致。
十一、结论
本次设计采用“单张结果总览员工结果表”作为结果总览页的唯一预聚合载体。
核心结论如下：
- 结果表粒度为
项目 + 员工。 - 员工亲属命中统一归并到员工本人。
- 命中结果写库成功后，同一事务内按项目整块重算结果表。
- 页面查询不再直接运行重连表聚合 SQL，而是基于结果表聚合或筛选。
- 模型卡片
warningCount继续保持原始标签命中次数口径。
该方案满足“最短路径实现、口径一致、页面查询降本”的目标，后续可据此输出前后端实施计划并进入实现阶段。