背景介绍
在系统开发过程中，有效管理和维护数据字典是非常重要的一步。这不仅能帮助我们保持数据的一致性，还能够提高数据的可追溯性。因此，在数据字典管理中引入版本控制机制显得尤为关键。
我们的平台已经拥有了一套现成的数据字典表，并计划通过工作流审批的方式来实现对这些字典条目的增删改查操作。下面，我将分享在这个需求开发过程中遇到的一些挑战和解决方案，希望能为大家提供一些参考。
数据库设计
为了满足上述需求，我们需要设计一个新的表结构来存储版本信息、状态以及工作流相关的细节等。此外，还需添加一个生效时间字段以更好地管理字典的有效期。下面是dict_info_history表的设计示例：
CREATE TABLE `dict_info_history` (
-- 原有字段
`status` int(4) DEFAULT NULL COMMENT '状态',
`workflow_node_seq` varchar(50) DEFAULT NULL COMMENT '工作流节点序号',
`version` int(8) DEFAULT 1 COMMENT '版本号',
`proposed_effective_time` datetime DEFAULT NULL COMMENT '拟生效日期',
PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC COMMENT='字典值历史记录';
工单审批流程图
计划开发的功能接口
- 查询包含版本信息的字典列表 √
- 获取最新的版本 √
- 工单提交前进行编码验证 √
- 完成工单后的字典更新操作 √
- 工单完成后的状态自动更新 √
- 设置拟生效日期（精确到天），并通过定时任务每日凌晨检查当天应生效的记录并立即应用 √
- 查询历史记录 √
| 序号 | 功能描述 | 遇到的问题及解决思路 |
|---|---|---|
| 1 | 查询包含版本信息的字典列表 | 1. 兼容性和扩展性：通过创建新表来保存历史版本记录的方式解决了这个问题。每当对实际使用的数据表做出修改时，都会先将其内容复制到历史表中，确保每个版本都有迹可循。 2. 初始化：由于这是一个扩展表，因此需要进行初始化。具体步骤如下：首先，当版本为1时，应复制原有表的数据；随后，再对版本为2的表进行数据复制。 |
| 2 | 获取最新的版本 | 1. 数据一致性校验：查询最新版本的字典时检查当前存储的数据与历史记录是否一致，不一致则版本+1 |
| 3 | 工单提交前进行编码验证 | 1. 并发处理：为防止多用户同时修改导致的数据混乱，每次操作前都必须核对传入的版本号；如果发现传入的版本号不是当前版本号加一，则阻止请求。 2. 未完成流程处理：进行中的流程或者完结但是未生效的流程工单，要能够识别并在适当时候给出提示或限制进一步的操作。 3. 传入字典code校验：对同一字典进行先删后加操作会报错，所以对code进行校验，重复则提示。 |
| 4 | 完成工单后的字典更新操作 | 1. 同一父级ID下的批量更新：当新增、修改或删除某项字典值时，需同步更新属于同一父级的所有相关条目。 |
| 5 | 工单完成后的状态自动更新 | 1. 版本更新：在查看最新版数据时，仅考虑那些已经被批准并且正式生效的内容；而那些被拒绝或是还未通过审核的部分则不会显示。每当有一份工单成功获得批准后，版本也会随之更新 |
| 6 | 设置拟生效日期（精确到天），并通过定时任务每日凌晨检查当天应生效的记录并立即应用 | √ |
| 7 | 查询历史记录 | √ |
设置了四个字典的状态来区分各种情况。
public interface SysDictInfoStatusConstants {
/**
* 字典状态 - 办理中
*/
Integer STATUS_IN_PROGRESS = 10;
/**
* 字典状态 - 已完结
*/
Integer STATUS_COMPLETED = 20;
/**
* 字典状态 - 已生效
*/
Integer STATUS_EFFECTIVE = 30;
/**
* 字典状态 - 已作废
*/
Integer STATUS_OBSOLETE = 40;
/**
* 默认字典状态 - 办理中
*/
Integer DEFAULT_STATUS = STATUS_IN_PROGRESS;
}
查询版本号时查询 30 状态的数据，在字典操作时把状态改为10，工单审批完结改为20，审批失败改为40，到达生效时间改为30.
难点：
- 工单沟通上，一些细节，参数命名问题，流程逻辑问题相关方面。
- 对公共平台的兼容性和之后的扩展性考虑上。
