做工作流数据库，建议先确定业务流程和状态流转规则，再用关系型数据库分别保存流程定义、流程实例、任务、操作记录和业务数据。核心不是画出几张表，而是保证每一次提交、审批、退回都能按规则执行，并留下可追溯记录；遇到并发处理、流程变更和异常恢复时，数据仍然一致。

一套能落地的工作流数据库，至少要回答五个问题：流程有哪些步骤，当前运行到哪里，谁可以处理，处理后进入哪里，以及之前发生过什么。下面以常见的申请审批流程为例，拆解数据库设计和实施顺序。

## 一、先确定工作流数据库要解决什么问题

工作流数据库用于保存流程运行所需的数据。它既要记录“应该怎样流转”，也要记录“某一次申请实际流转到了哪里”。这两类信息如果混在一起，流程一旦修改，就容易影响已经提交的申请。

假设一个请假申请需要经过提交、负责人审批和结果通知。设计时可以把数据分成三层：

第一层是**流程定义**，记录流程有哪些节点、节点之间如何连接、什么条件下走哪条路径，以及节点由谁处理。它相当于流程规则，不代表某一位员工的具体申请。

第二层是**流程运行数据**，记录每一笔申请对应的流程实例、当前待办任务、处理结果和操作时间。例如，同一套请假流程可以同时运行多个实例，每个实例有自己的申请人、当前状态和审批记录。

第三层是**业务数据**，记录请假类型、起止时间、请假原因等具体内容。不同业务的字段差异很大，不宜全部塞进通用流程表。

这三层之间需要关联，但职责应当分开。流程实例知道自己对应哪条业务记录、使用哪个流程定义版本；任务知道自己属于哪个实例和哪个节点；业务记录则保存业务内容。这样既能查询一笔申请的审批进度，也能避免每增加一种业务就修改一遍流程引擎的核心结构。

### 判断需要做到什么程度

不是所有审批都需要一套完整的流程引擎。如果业务只有固定的两个状态，处理人也不会变化，用业务表中的状态字段加操作记录，可能已经足够。为了一个简单动作设计可视化流程编排、复杂分支和动态加签，反而会增加维护负担。

当多个业务需要复用审批能力、处理路径会变化，或必须保留详细审计记录时，才更适合建设相对通用的工作流数据库。即便如此，也建议从一个真实流程入手，先验证基础模型，再逐步扩展，而不是一开始就试图覆盖所有流程类型。

## 二、工作流数据库的核心表怎么设计

工作流数据库的表结构可以复杂也可以简单，但下面几类数据通常不能混为一谈。表名不必完全一致，关键是每张表的职责清楚、关联关系明确。

| 数据对象 | 主要保存内容 | 设计重点 |
| --- | --- | --- |
| 流程定义表 | 流程标识、名称、版本、启用状态 | 已发布版本应可识别，避免直接覆盖历史规则 |
| 流程节点表 | 节点类型、节点标识、处理规则 | 节点标识在所属版本内保持稳定且唯一 |
| 流转关系表 | 起始节点、目标节点、流转条件 | 保存路径及条件，明确无匹配路径时的处理方式 |
| 流程实例表 | 发起人、关联业务、定义版本、实例状态 | 一次申请对应一个实例，并固定所用版本 |
| 任务表 | 所属实例、节点、处理人、任务状态 | 明确待办、已处理、取消等状态及处理权限 |
| 操作记录表 | 操作人、动作、意见、时间、前后状态 | 作为追溯依据，避免被普通业务更新覆盖 |
| 业务表 | 申请内容和业务状态 | 与流程数据关联，但不依赖通用表承载全部业务字段 |

### 流程定义、节点和流转关系

流程定义表描述一套流程的基本信息，例如流程标识、名称、版本号、发布状态。节点表描述开始、审批、结束等步骤，流转关系表则连接节点，并保存流转条件。

将节点和路径分开，是因为一个节点可能有多个后续去向。例如，审批通过后进入下一级，审批拒绝后直接结束；金额或申请类型不同，也可能进入不同处理节点。设计时应明确条件使用哪些业务字段、允许哪些比较方式，以及多条路径同时满足条件时如何处理。

对于刚开始建设的系统，条件规则不宜过于开放。可以先支持有限的字段比较和明确的优先顺序，避免把难以校验的复杂表达式直接交给流程配置人员。若没有任何路径匹配，应让流程停在可诊断的状态并提示管理员，而不是默认进入某个节点。

### 流程实例和任务

流程实例代表一次具体运行。实例通常需要保存流程定义版本、业务类型、业务记录标识、发起人、开始时间、结束时间和实例状态。

任务则代表某个节点上需要处理的一项工作。单人审批时，一个节点可能只有一条待办；多人审批时，一个节点可能产生多条任务。因此，不能简单地把“当前处理人”作为流程实例中唯一的人员字段，否则很难表达并行会签、候选人认领等场景。

任务状态至少应能区分待处理、已处理和已取消。是否进一步区分已认领、已转交等状态，要看业务是否真的需要。字段越多不一定越好，但每个状态必须有明确含义和允许的后续动作。

### 操作记录与业务数据

操作记录应保存关键动作的发生事实，包括操作者、动作类型、所属实例和任务、操作时间、处理意见，以及必要的状态变化信息。审批意见可以修改还是只能补充，应由业务和审计要求决定，不能默认允许覆盖。

业务表保留领域字段。例如请假申请保存请假时间和原因，费用申请保存金额和费用说明。流程实例可以通过业务类型和业务记录标识关联业务表；如果采用这种通用关联方式，数据库未必能直接对所有业务表建立外键，需要在应用层做好引用校验、删除限制和定期检查。

**不要把业务字段、流程配置和审批历史全部放进一张大表。**早期看似省事，后续一旦出现多次审批、多个处理人或流程版本变化，就容易出现字段重复、历史被覆盖和查询逻辑难以维护的问题。

## 三、按照状态流转把流程真正跑通

表结构只是基础，工作流能否可靠运行，取决于状态和动作是否被严格约束。建议先用一个简单审批流程，把提交、通过、驳回、撤回和结束等动作走通，再考虑复杂分支。

### 明确实例状态与任务状态

实例状态描述整笔流程的生命周期，可以根据业务需要设置为草稿、运行中、已完成、已拒绝、已撤回等。任务状态描述具体处理事项的生命周期，两者不能互相代替。

例如，一笔申请仍处于运行中，并不意味着所有任务都待处理：前一个审批任务可能已经完成，当前节点的任务才是待办。多人的并行审批中，部分任务完成后，实例也未必立即进入下一节点。

状态定义时，要同时写清楚允许的转换关系。草稿可以提交，运行中的实例在符合条件时可以撤回；已完成的实例通常不能直接回到运行中。如果业务允许重新申请，更稳妥的方式通常是新建实例并关联原申请，而不是抹掉已经结束的历史。

### 一次审批需要完成哪些数据库动作

处理人点击“通过”时，服务端不能只把任务状态改成已完成。一个完整动作通常包括：校验任务仍可处理、确认当前用户有权限、记录审批结果、判断后续节点、更新实例状态，并按规则创建新的任务或结束实例。

这些数据库写入应放在同一个事务中，使其作为一个整体成功或回滚。否则，可能出现任务已经完成、下一节点待办却没有创建的情况；也可能已经写入审批记录，实例状态却没有更新。

发送消息、调用外部服务等操作应谨慎处理。外部系统通常无法与本地数据库事务天然保持一致，不能简单认为“数据库提交成功，通知也一定成功”。较常见的做法是在事务内保存待发送事件，提交后再由可靠的后台机制投递，并设计重试与去重。具体方案需要结合系统架构决定。

### 处理并发、重复提交和认领冲突

同一任务可能被用户连续点击，也可能被多个候选处理人同时操作。若系统只在页面打开时检查一次任务状态，就可能产生重复审批、重复创建下一节点任务等问题。

服务端应在执行动作时再次校验任务状态，并采用条件更新、版本号或数据库锁等方式控制并发。处理结果还要检查实际更新的记录数：只有成功取得处理权的请求才能继续推进流程，其他请求应得到明确提示。

对可能重复到达的请求，应设计幂等机制。例如，为一次操作使用可识别的请求标识，并对关键写入设置适当的唯一约束。幂等不等于忽略所有重复请求：如果同一标识对应的内容不一致，系统应拒绝或记录异常，而不是悄悄返回成功。

### 退回、撤回与多人审批要提前定规则

“退回”不是简单地把当前节点编号减一。系统需要明确退回到发起人、指定历史节点，还是重新走完整审批链；退回后原任务如何关闭，新任务由谁处理，之前的审批记录是否继续展示，也都应有确定规则。

撤回同样存在边界。例如，申请人是否能在审批人已处理后撤回，需要业务明确。撤回时应同步关闭尚未处理的任务，并记录撤回动作，避免待办列表仍显示可审批事项。

多人审批还要区分处理规则：是所有人同意才通过，还是任一人处理即可推进。若某个结果已经足以决定节点走向，应及时取消不再需要的待办，并防止其他人继续处理。人员变更、转交和加签会进一步增加复杂度，建议在基础流程稳定后再引入。

## 四、按什么顺序建设，才能减少返工

工作流数据库的建设顺序，比一次性设计多少张表更重要。比较稳妥的做法是从规则清晰、参与角色较少的流程开始，用真实业务约束验证模型，再逐步增加能力。

### 先梳理流程，再决定字段

在建表之前，先把一次申请从创建到结束的路径写清楚。重点不是画得多漂亮，而是确认每一步的触发条件、处理人、允许动作和异常去向。

例如，请假申请被驳回后，是直接结束，还是允许修改后重新提交？负责人离职时，待办如何处理？发起人提交后发现内容错误，能否撤回？这些问题如果没有答案，数据库字段即使设计得很完整，开发阶段仍然会反复修改。

梳理时也要区分“当前需要”和“未来可能需要”。眼下只存在单人审批，就先确保单人审批可靠运行；多人会签可以预留扩展空间，但不必为了不确定的需求提前引入完整的复杂机制。

### 再设计关联、约束和查询

确定流程后，再设计主键、关联字段、非空约束、唯一约束和索引。比如，节点标识通常需要在所属流程版本范围内唯一；任务应能关联到实例及相应节点；关键操作记录应能定位到具体实例和任务。

索引应围绕实际查询建立。待办列表通常按处理人、任务状态和创建时间筛选，流程详情通常按实例标识查询任务和操作记录，管理查询则可能按业务类型、发起人和时间范围筛选。具体索引组合需要结合数据库类型、数据规模和查询计划验证，不能只凭字段数量决定。

业务状态与流程状态也要约定权威来源。比如审批通过后，流程实例显示已完成，业务记录显示已生效；两者如何同步、同步失败如何发现，都应在设计时确定。不要让两个状态各自更新，却没有一致性检查和修复方式。

### 发布前验证正常路径和异常路径

测试不能只验证“提交后审批通过”。还应覆盖驳回、撤回、重复点击、两人同时处理、审批人失效、流转条件无匹配等情况，并检查数据库最终状态是否与页面一致。

对于每个关键动作，可以用同一套问题验收：操作完成后，实例状态是否正确，旧任务是否关闭，新任务是否按规则产生，操作记录是否完整，重复请求是否造成额外影响。异常发生后，还要检查事务是否回滚、是否留下可定位的问题记录。

上线后应具备基本的运维能力，包括查询卡住的实例、识别长期未处理任务、查看失败事件，以及按照授权流程修复异常。人工修复需要保留操作记录，避免直接改数据库后无法解释历史变化。

## 五、重点防住流程版本和权限两类落地难点

基础流程跑通后，最容易导致返工的往往不是新增字段，而是流程规则变化和权限边界不清。这两类问题会直接影响历史数据可信度，应在系统投入使用前明确。

### 流程修改后，已运行的实例怎么办

流程上线后，审批节点、处理人规则或分支条件可能发生变化。如果直接覆盖原有定义，旧实例查询时可能套用新规则，导致历史路径无法还原，甚至让正在运行的任务找不到对应节点。

较稳妥的方式是让流程定义具有版本：发布新规则时生成新版本，新发起的实例使用新版本，已运行实例默认继续使用原版本。实例创建时应固定所引用的版本，而不是每次运行都读取“最新定义”。

这并不意味着旧流程永远不能迁移。如果确有必要让运行中的实例切换版本，需要单独制定迁移规则，确认节点如何映射、已有任务如何处理、哪些实例不能迁移，并在操作前后保留记录。涉及复杂分支时，应先在可控范围内验证，不能把“改版本号”当作完整迁移方案。

处理人规则也要明确取值时机。例如，节点处理人可以在发起时确定，也可以在流程到达该节点时根据当时的组织关系计算。两种方式各有适用场景，关键是提前约定并记录最终结果，避免事后无法解释某项任务为何分配给特定人员。

### 谁能查看、处理和修改数据

数据库中保存了申请内容、审批意见和人员信息，权限设计不能只依赖前端是否显示按钮。服务端在查询详情、领取任务、审批或撤回时，都需要检查用户身份、实例范围和当前动作权限。

处理权限与查看权限也不完全相同。申请人通常需要查看自己发起的流程，当前处理人需要查看完成审批所必需的信息，管理人员可能因职责需要查看更大范围的数据。具体范围应由业务和组织要求确定，不宜默认所有参与者都能查看全部历史和敏感字段。

操作记录应尽量保持可追溯，普通用户不应直接删除或覆盖关键历史。对于确需更正的数据，应通过受控动作补充说明，并记录操作者和原因。数据库账号也应按职责分配权限，日常应用账号不必拥有与运维账号相同的管理权限。

权限还要覆盖人员变化。审批人离岗、部门调整或账号停用后，待办不能长期无人处理，但也不能自动交给任意人员。应提前规定代理、转交或管理员介入的条件，并记录实际处理人及处理依据。

## 六、总结

做工作流数据库，应先明确流程规则，再分开设计流程定义、运行实例、任务、操作记录和业务数据。让状态转换有约束、关键写入在事务中保持一致，并对并发和重复请求做好处理，才能让审批过程可靠运行。

落地时不必一开始追求覆盖所有场景。选择一条规则清晰的流程，把正常流转和异常处理验证完整，再逐步扩展分支与多人协作；同时固定流程版本、划清权限边界，让正在运行的实例和历史记录都能解释、查询和追溯。

通常需要存储流程定义、流程节点、节点流转规则、流程实例、任务、审批记录和操作日志。流程定义描述规则，流程实例记录每次发起的业务，任务和审批记录用于跟踪处理过程。

核心数据表

设计工作流数据库时，通常需要建立哪些数据表？

工作流数据库需要存储哪些核心数据？

可以建立节点流转关系表，保存起始节点、目标节点、流转条件和优先级。流程运行时，根据业务数据计算条件，再确定可到达的节点。涉及并行分支时，还需要记录分支状态和汇合规则。

使用流转关系表

流程中存在分支或条件判断时，数据库应该如何表示节点之间的关系？

如何设计流程节点之间的流转关系？

为流程定义设置版本号，并让每个流程实例绑定启动时使用的版本。修改流程时创建新版本，新发起的实例使用新版本，运行中的实例继续使用原版本。需要迁移实例时，应制定迁移规则并验证节点和任务状态。

通过版本管理隔离变更

调整审批节点或流转规则时，如何避免影响已发起的流程？

流程修改后会影响正在运行的审批吗？

将任务状态更新、审批记录写入和节点流转放在同一个数据库事务中，并通过版本号、条件更新或行锁控制并发。对重复请求设置幂等标识，避免同一操作被多次执行。

结合事务与并发控制

多个审批人同时处理任务，或者同一任务被重复提交时，怎样避免状态混乱？

如何保证多人审批时的数据一致性？

任务表可以记录处理人、任务状态、流程实例 ID 和创建时间，并根据查询条件建立组合索引。流程进度可通过实例状态、节点状态和操作日志展示；数据量较大时，应结合实际查询计划优化索引和分页方式。

围绕常用查询建立索引

数据库设计需要支持个人待办、已办记录和流程进度查询，应该注意什么？

怎样查询待办任务和流程进度？

PingCodeDocs

工作流数据库应先梳理业务规则，再分别设计流程定义、节点与流转关系、流程实例、任务、操作记录和业务数据。实施时要明确状态转换，使用事务保障关键写入一致，并处理并发审批、重复提交、退回撤回、流程版本变更和权限控制。建议从简单流程入手，验证正常与异常路径后再扩展复杂场景。

怎么做工作流数据库