OA审批流数据库设计：表结构拆分与流转落库实战

简介这份PDF文档面向企业信息化建设者、后端开发与数据库设计人员聚焦OA系统中流程审批模块的数据库建模问题帮助读者理清审批流程从发起到归档的完整数据支撑思路。内容围绕流程实例表、活动实例表、审批任务表、规则配置表、历史版本表以及用户与角色权限表等核心结构展开讲解各表字段含义、表间关联关系与状态流转设计并涉及条件判断、审批权限分配、历史追溯与审计等实际场景同时提及索引、分区等性能优化方向。资源包内共1个PDF文件压缩包约35KB篇幅精炼适合作为数据库表结构设计的参考模板或方案速查。目前已有743人学习下载读者可从中获取审批流程数据模型的整体框架、关键字段定义与扩展性设计思路用于指导自身系统的表结构落地与后续迭代。1. 审批流数据库到底难在哪从一张请假单说起很多团队做 OA 系统前端页面画得飞快流程引擎也选型完毕结果上线两周就卡在数据库上审批节点一改历史单据全乱一个人转岗待办列表里冒出几百条脏数据想查「谁在什么时间把单子打回给谁」翻遍日志表也拼不出完整链路。问题不在引擎而在流程审批数据库的设计从一开始就没把「流程定义」和「流程实例」分开。这篇内容讲的是 OA 系统中流程审批模块的数据库设计覆盖表结构怎么拆、节点和流转怎么落库、审批记录怎么留痕、并发和撤回怎么处理。适合正在自研 OA 的后端同学、需要给现有系统补审批模块的开发者以及被「流程一改数据就崩」折磨过的维护者。读完你能拿到一套可直接建表的方案也能看清哪些字段是后悔药哪些设计是血泪经验换来的。2. 流程审批数据库的表结构拆分定义、实例、任务三分离流程审批数据库设计最容易翻车的地方是把「流程长什么样」和「这张单子走到哪了」塞进同一张表。前者是模板后者是运行态生命周期完全不同。模板可能一年改三次运行态单据每天都在产生。混在一起改模板就会污染历史数据。2.1 为什么必须拆成流程定义表和流程实例表先看一个真实场景公司把「报销审批」从两级改成三级如果流程配置和单据数据在同一张表那么改完配置后所有在途单据的审批路径会被一起改写原本只需要总监签字的单子突然多出一个财务复核节点历史已完成的单据也会显示成「未走完」。这不是引擎的锅是表结构没有隔离。常见做法是拆成三层流程定义层模板、流程实例层单据、任务层待办。定义层描述「这类流程有几个节点、什么顺序、谁审批」实例层描述「这张具体单据当前处于哪个节点、状态是什么」任务层描述「当前这个节点该谁处理、处理结果是什么」。三层通过外键关联模板变更只影响新发起的实例在途实例按发起时快照走。这里有个关键决策实例要不要保存流程定义的快照。我一般会存。因为流程定义随时可能被修改甚至删除如果实例只存一个 definition_id半年后想还原这张单子当时走的路径定义已经变了查不出来。快照可以是一个 JSON 字段也可以是独立的实例节点表前者省事后者便于按节点查询。2.2 核心表结构设计与建表语句下面这套表结构是我在多个 OA 项目里沉淀下来的字段做了精简保留关键部分。数据库以 MySQL 8.0 为例字符集统一 utf8mb4。-- 流程定义表描述一类审批流程的模板 CREATE TABLE wf_definition ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, def_key VARCHAR(64) NOT NULL COMMENT 流程标识如 leave_approval, def_name VARCHAR(128) NOT NULL COMMENT 流程名称如 请假审批, version INT NOT NULL DEFAULT 1 COMMENT 版本号同 key 可多版本, status TINYINT NOT NULL DEFAULT 0 COMMENT 0草稿 1启用 2停用, form_schema JSON NULL COMMENT 表单字段定义, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_key_version (def_key, version), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT流程定义表; -- 流程节点表定义某个版本下有哪些节点 CREATE TABLE wf_node ( id BIGINT NOT NULL AUTO_INCREMENT, definition_id BIGINT NOT NULL COMMENT 所属流程定义, node_key VARCHAR(64) NOT NULL COMMENT 节点标识如 dept_manager, node_name VARCHAR(128) NOT NULL COMMENT 节点名称如 部门经理审批, node_type TINYINT NOT NULL COMMENT 1审批 2抄送 3条件 4开始 5结束, approver_type TINYINT NOT NULL DEFAULT 1 COMMENT 1指定人 2角色 3部门主管 4发起人自选, approver_value VARCHAR(255) NULL COMMENT 审批人标识角色ID或用户ID, sort_no INT NOT NULL DEFAULT 0 COMMENT 节点顺序, next_node_key VARCHAR(64) NULL COMMENT 默认下一节点, PRIMARY KEY (id), KEY idx_def (definition_id, sort_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT流程节点定义表; -- 流程实例表一张具体单据的运行态 CREATE TABLE wf_instance ( id BIGINT NOT NULL AUTO_INCREMENT, definition_id BIGINT NOT NULL COMMENT 发起时的流程定义ID, def_snapshot JSON NULL COMMENT 发起时的流程快照防止定义变更影响在途, biz_key VARCHAR(64) NOT NULL COMMENT 业务单据标识如报销单号, biz_type VARCHAR(32) NOT NULL COMMENT 业务类型如 expense, title VARCHAR(255) NOT NULL COMMENT 单据标题用于待办展示, initiator_id BIGINT NOT NULL COMMENT 发起人, current_node VARCHAR(64) NULL COMMENT 当前节点key, status TINYINT NOT NULL DEFAULT 1 COMMENT 1审批中 2通过 3驳回 4撤回 5作废, started_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, finished_at DATETIME NULL, PRIMARY KEY (id), KEY idx_biz (biz_type, biz_key), KEY idx_initiator (initiator_id, status), KEY idx_status_node (status, current_node) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT流程实例表; -- 审批任务表每个节点产生的待办/已办 CREATE TABLE wf_task ( id BIGINT NOT NULL AUTO_INCREMENT, instance_id BIGINT NOT NULL COMMENT 所属实例, node_key VARCHAR(64) NOT NULL COMMENT 节点标识, node_name VARCHAR(128) NOT NULL COMMENT 节点名称冗余便于列表展示, assignee_id BIGINT NOT NULL COMMENT 处理人, action TINYINT NULL COMMENT 1同意 2驳回 3转办 4加签, comment VARCHAR(500) NULL COMMENT 审批意见, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待办 1已办 2已取消, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, handled_at DATETIME NULL, PRIMARY KEY (id), KEY idx_assignee_status (assignee_id, status), KEY idx_instance (instance_id, node_key) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT审批任务表;这套结构的关键点wf_instance里的def_snapshot是后悔药流程定义改了也不影响在途单据wf_task里冗余了node_name因为待办列表要展示节点名如果每次都 join 定义表定义一改历史任务显示就变了assignee_id加status的联合索引是待办列表查询的核心索引没有它用户待办一多就慢。参数说明def_key和version做唯一键支持同一流程多版本共存新版本启用后老实例继续走老版本。status用 TINYINT 而不是字符串省空间且索引效率高。form_schema用 JSON 存表单定义MySQL 8.0 支持 JSON 索引如果表单字段需要检索可以加虚拟列。2.3 审批记录留痕表怎么查「谁在什么时候做了什么」任务表只记录当前节点的处理结果但审批过程中还有转办、加签、撤回、催办这些动作如果都塞进任务表字段会爆炸。我一般单独建一张操作日志表只追加不修改。CREATE TABLE wf_operation_log ( id BIGINT NOT NULL AUTO_INCREMENT, instance_id BIGINT NOT NULL, task_id BIGINT NULL COMMENT 关联任务部分操作无任务, operator_id BIGINT NOT NULL COMMENT 操作人, op_type VARCHAR(32) NOT NULL COMMENT APPROVE/REJECT/TRANSFER/ADD_SIGN/WITHDRAW/URGE, from_node VARCHAR(64) NULL, to_node VARCHAR(64) NULL, detail JSON NULL COMMENT 操作详情如转办目标人, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_instance_time (instance_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT审批操作日志表;这张表是黑匣子出问题时全靠它还原现场。op_type用字符串而不是数字因为操作类型会随业务扩展字符串可读性更好且这张表写入量远小于任务表空间换可读性划算。detail用 JSON 存差异化字段避免为每种操作加列。3. 流程流转的落库逻辑从发起到归档的完整链路表建好了接下来是流转逻辑。流程审批数据库设计里流转是最容易写出并发 bug 的地方。两个人同时审批同一个节点、撤回和审批同时发生、加签后原审批人还能不能操作这些都要在数据库层面兜住。3.1 发起流程实例创建与首个任务生成发起流程时要做三件事写实例、生成首个任务、写操作日志。这三步必须在同一个事务里否则会出现实例创建了但没有待办任务的脏数据。def start_process(def_key, biz_type, biz_key, title, initiator_id, form_data): with db.transaction(): # 1. 取当前启用的流程定义 definition db.query_one( SELECT * FROM wf_definition WHERE def_key%s AND status1 ORDER BY version DESC LIMIT 1, (def_key,)) if not definition: raise BizError(流程未启用) # 2. 取定义下的节点生成快照 nodes db.query( SELECT * FROM wf_node WHERE definition_id%s ORDER BY sort_no, (definition[id],)) snapshot {nodes: nodes, version: definition[version]} # 3. 写实例 instance_id db.insert(wf_instance, { definition_id: definition[id], def_snapshot: json.dumps(snapshot), biz_key: biz_key, biz_type: biz_type, title: title, initiator_id: initiator_id, current_node: nodes[0][node_key], status: 1 }) # 4. 解析首个节点的审批人并生成任务 assignees resolve_assignees(nodes[0], initiator_id, form_data) for uid in assignees: db.insert(wf_task, { instance_id: instance_id, node_key: nodes[0][node_key], node_name: nodes[0][node_name], assignee_id: uid, status: 0 }) # 5. 写操作日志 db.insert(wf_operation_log, { instance_id: instance_id, operator_id: initiator_id, op_type: START, to_node: nodes[0][node_key] }) return instance_id逻辑说明resolve_assignees是审批人解析函数根据节点的approver_type决定审批人。如果是「部门主管」需要查发起人所在部门的负责人如果是「角色」查角色下的用户如果是「发起人自选」从form_data里取。这个函数是流程引擎的核心扩展点不同公司规则不同但接口要统一。参数说明def_snapshot存的是发起时刻的节点列表后续流转全部基于快照不再查wf_node。这样即使管理员改了流程定义在途单据也不受影响。代价是快照占空间但一条 JSON 通常几 KB可接受。3.2 审批通过节点推进与任务状态更新审批通过是最常见的操作逻辑是校验任务归属、更新任务状态、判断当前节点是否全部处理完、推进到下一节点或结束实例。def approve(task_id, operator_id, comment): with db.transaction(): # 1. 锁定任务行防止并发重复审批 task db.query_one( SELECT * FROM wf_task WHERE id%s FOR UPDATE, (task_id,)) if not task or task[status] ! 0: raise BizError(任务不存在或已处理) if task[assignee_id] ! operator_id: raise BizError(无权处理该任务) # 2. 更新任务为已办 db.update(wf_task, { action: 1, comment: comment, status: 1, handled_at: now() }, where{id: task_id}) # 3. 判断同节点是否还有未处理任务会签场景 pending db.query_one( SELECT COUNT(*) AS c FROM wf_task WHERE instance_id%s AND node_key%s AND status0, (task[instance_id], task[node_key])) if pending[c] 0: return # 会签未完成等待其他人 # 4. 取实例快照找下一节点 instance db.query_one( SELECT * FROM wf_instance WHERE id%s FOR UPDATE, (task[instance_id],)) snapshot json.loads(instance[def_snapshot]) next_node find_next_node(snapshot, task[node_key]) # 5. 推进或结束 if next_node is None: db.update(wf_instance, { status: 2, current_node: None, finished_at: now() }, where{id: instance[id]}) else: assignees resolve_assignees(next_node, instance[initiator_id], None) for uid in assignees: db.insert(wf_task, { instance_id: instance[id], node_key: next_node[node_key], node_name: next_node[node_name], assignee_id: uid, status: 0 }) db.update(wf_instance, { current_node: next_node[node_key] }, where{id: instance[id]}) db.insert(wf_operation_log, { instance_id: instance[id], task_id: task_id, operator_id: operator_id, op_type: APPROVE, from_node: task[node_key], to_node: next_node[node_key] if next_node else None })逻辑说明FOR UPDATE是并发控制的关键。两个人同时点同意第一个事务锁住任务行第二个事务等待等第一个提交后第二个读到status1直接报「已处理」避免重复推进。第 3 步的会签判断如果同节点还有待办就不推进等所有人处理完。参数说明find_next_node根据快照里的next_node_key找下一节点如果节点是条件类型需要根据表单数据判断走哪个分支。条件分支的表达式可以存在wf_node的扩展字段里这里简化处理。3.3 驳回、撤回与转办三种特殊流转的落库差异驳回和同意不同驳回要决定回到哪个节点。常见做法是驳回到发起人或者驳回到上一个审批节点。我一般让发起人配置默认驳回到发起人。def reject(task_id, operator_id, comment, target_nodeNone): with db.transaction(): task db.query_one( SELECT * FROM wf_task WHERE id%s FOR UPDATE, (task_id,)) if not task or task[status] ! 0: raise BizError(任务不存在或已处理) db.update(wf_task, { action: 2, comment: comment, status: 1, handled_at: now() }, where{id: task_id}) instance db.query_one( SELECT * FROM wf_instance WHERE id%s FOR UPDATE, (task[instance_id],)) # 驳回目标默认发起人节点也可指定 back_node target_node or start db.update(wf_instance, { status: 3, current_node: back_node }, where{id: instance[id]}) # 取消同实例其他待办任务 db.update(wf_task, {status: 2}, where{instance_id: instance[id], status: 0}) db.insert(wf_operation_log, { instance_id: instance[id], task_id: task_id, operator_id: operator_id, op_type: REJECT, from_node: task[node_key], to_node: back_node })撤回是发起人的特权只能撤回还在审批中、且没有其他人处理过的单据。转办是把当前任务换个人任务本身不结束只换assignee_id。这三种操作的共同点是都要写操作日志且都要在事务里锁实例行防止和审批操作交叉。4. 审批数据库的避坑与排查五个真实踩坑记录4.1 待办列表越查越慢索引没建对现象上线三个月后用户待办列表加载超过 3 秒DBA 发现wf_task全表扫描。原因待办查询条件是assignee_id ? AND status 0但只建了assignee_id单列索引MySQL 优化器在数据量大时可能不走索引或者走索引后回表过滤status效率低。解决建(assignee_id, status)联合索引且顺序不能反。status区分度低放后面。如果还有按时间排序可以再加created_at做覆盖索引。建完后用EXPLAIN确认typeref、keyidx_assignee_status。4.2 流程定义改了在途单据节点错乱现象管理员把请假流程从两级改成三级结果所有在途单据的当前节点显示成新流程的节点名历史审批记录对不上。原因实例表只存了definition_id流转时实时查wf_node定义一改在途单据跟着变。解决实例表加def_snapshot字段发起时把节点列表序列化存进去后续流转只读快照。已经上线的系统可以写迁移脚本给在途实例补快照补的时候用当前定义虽然不完美但能止血。4.3 并发审批导致重复推进现象同一个节点有两个审批人两人同时点同意结果流程直接跳过了下一个节点或者下一节点生成了两份任务。原因审批逻辑没有加行锁两个事务同时读到任务status0都执行了推进。解决查询任务时加FOR UPDATE并在更新任务状态时加WHERE status0条件用影响行数判断是否更新成功。如果affected_rows0说明已被处理直接返回。这是乐观锁和悲观锁的结合用法。4.4 转办后原审批人还能操作现象A 把任务转给 BB 还没处理A 的待办列表里还能看到这条任务并点同意。原因转办只更新了assignee_id但前端缓存了旧数据或者查询待办时没有实时过滤。解决转办时除了更新assignee_id还要写操作日志并且前端待办列表每次进入都重新拉取。如果用了缓存转办后要主动失效相关用户的缓存。数据库层面待办查询始终以wf_task当前assignee_id为准不要冗余到其他表。4.5 驳回后重新提交历史任务状态混乱现象单据被驳回后发起人修改重新提交原来的审批任务还显示「待办」新任务又生成了用户看到两条待办。原因驳回时只更新了实例状态没有取消同实例的其他待办任务。解决驳回逻辑里加一步把该实例下所有status0的任务批量更新为status2已取消。重新提交时生成全新任务历史任务保留但状态为已取消查询待办时只查status0就不会重复。5. 进阶技巧用状态机校验和归档策略让审批库长期可维护前面讲的都是单点设计这一章说两个让审批库能扛住长期运行的习惯。第一个习惯是给实例状态加状态机校验。wf_instance.status有审批中、通过、驳回、撤回、作废五种不是任意状态都能互相跳转。比如「通过」不能直接变「审批中」「作废」不能变「通过」。我一般会在代码里维护一张状态转移表每次更新前校验不合法直接抛异常。这样能挡住很多因为代码分支写错导致的状态污染。TRANSITIONS { 1: [2, 3, 4, 5], # 审批中 - 通过/驳回/撤回/作废 2: [], # 通过 - 终态 3: [1, 5], # 驳回 - 重新提交(审批中)/作废 4: [1, 5], # 撤回 - 重新提交/作废 5: [] # 作废 - 终态 } def update_instance_status(instance_id, new_status): inst db.query_one(SELECT status FROM wf_instance WHERE id%s, (instance_id,)) if new_status not in TRANSITIONS.get(inst[status], []): raise BizError(f非法状态转移: {inst[status]} - {new_status}) db.update(wf_instance, {status: new_status}, where{id: instance_id})第二个习惯是归档策略。审批任务表是增长最快的表一年可能几百万行。如果一直不归档待办查询会越来越慢。我的做法是按finished_at分区或者定期把已完成超过一年的实例和任务迁移到历史库。迁移时保留wf_instance主表记录只把wf_task和wf_operation_log的明细搬走查询历史时走历史库。这样主表始终保持在可控规模待办查询不受影响。还有一个容易被忽略的点审批意见字段comment用VARCHAR(500)但实际业务里有人粘贴大段文字超长会报错。我一般改成TEXT或者在前端限制字数并在后端截断。这个坑不常遇到但遇到一次就要改表不如一开始就留够。最后说个我自己的教训早期做 OA 时我觉得流程定义不会经常改实例表没存快照结果业务部门一个月改了四次审批流在途单据全乱加班写数据修复脚本。从那以后凡是流程引擎相关的表我都坚持「运行态存快照、定义态可版本化、操作全留痕」这三条。数据库设计没有银弹但把这三条做到位能省掉后面 80% 的救火时间。希望帮到你。本文还有配套的精品资源点击获取