用两张核心表重构OA多级审批系统从硬编码到动态配置的范式转移当企业OA系统需要支持第十种审批表单时开发团队突然发现新增一个请假流程需要修改三处状态判断代码调整五处审批人获取逻辑甚至还要重写通知模版——这种场景在传统硬编码审批系统中屡见不鲜。本文将揭示如何通过主表明细表的极简设计实现可适配任意审批场景的通用流程引擎并以加班申请为例展示从表结构设计到复杂查询的完整SQL实践。1. 为什么传统审批系统必然走向重构某中型互联网公司的技术负责人曾向我展示他们的OA审批代码库在leave_approval.py中从部门主管到HR的六级审批逻辑被写成了一连串的if-else嵌套而reimbursement_approval.js里又重复实现了几乎相同的状态机转换。这种每新增一个审批类型就复制一套流程的做法导致了三个典型问题维护成本指数增长每次流程变更都需要在多处同步修改历史数据迁移困难当审批规则调整时旧数据的兼容处理成为噩梦动态调整能力缺失临时增加审批层级需要发布新版本-- 典型硬编码审批查询示例请假流程专用 SELECT * FROM leave_application WHERE department_id 5 AND status IN (pending_director, pending_hr);相比之下基于核心表的动态审批系统通过流程配置数据化解决了这些问题。其本质是将审批规则从代码迁移到数据库使流程变更成为数据操作而非代码修改。2. 核心表设计的黄金法则最小化与扩展性2.1 主表设计流程实例容器audit_flow表作为所有审批流程的根容器只需关注流程实例本身的元信息与具体业务类型解耦字段名类型说明设计要点flow_noVARCHAR(50)唯一流程编号前缀包含日期(yyyyMMdd)便于归档bus_typeVARCHAR(20)业务类型标识符对应各业务表如overtimetitleNVARCHAR(50)动态标题如张三的加班申请支持模板字符串拼接initiator_idVARCHAR(20)发起人ID关联用户体系statusTINYINT全局状态(1待审/2通过/3驳回)使用状态码而非字符串-- 主表创建SQLMySQL语法 CREATE TABLE audit_flow ( flow_no VARCHAR(50) PRIMARY KEY, bus_type VARCHAR(20) NOT NULL COMMENT 业务类型代码, title NVARCHAR(50) NOT NULL COMMENT 流程标题, initiator_id VARCHAR(20) NOT NULL COMMENT 发起人ID, status TINYINT DEFAULT 1 NOT NULL COMMENT 1待审 2通过 3驳回, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;2.2 明细表设计动态审批链audit_flow_detail表的核心创新在于用数据驱动替代硬编码审批链每条记录代表一个审批环节字段名类型说明关键设计idBIGINT自增主键无业务意义flow_noVARCHAR(50)关联主表级联删除auditor_idVARCHAR(20)审批人ID支持角色ID或具体用户IDsequenceSMALLINT审批顺序实现会签/或签逻辑statusTINYINT环节状态(1待审/2通过/3驳回)独立于主表状态commentNVARCHAR(500)审批意见支持富文本-- 明细表创建SQL含索引优化 CREATE TABLE audit_flow_detail ( id BIGINT PRIMARY KEY AUTO_INCREMENT, flow_no VARCHAR(50) NOT NULL, auditor_id VARCHAR(20) NOT NULL, sequence SMALLINT NOT NULL COMMENT 审批顺序, status TINYINT DEFAULT 1 NOT NULL COMMENT 1待审 2通过 3驳回, comment NVARCHAR(500), operate_time DATETIME, FOREIGN KEY (flow_no) REFERENCES audit_flow(flow_no) ON DELETE CASCADE, INDEX idx_auditor_status (auditor_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;设计验证当需要实现部门主管→财务→CEO的三级审批时只需向明细表插入三条记录通过sequence字段控制审批顺序无需修改任何代码。3. 实战加班申请的全流程SQL实现3.1 业务表设计范式以加班申请为例业务表只需关注业务属性流程控制完全交给核心表CREATE TABLE overtime_application ( flow_no VARCHAR(50) PRIMARY KEY, applicant_id VARCHAR(20) NOT NULL, start_time DATETIME NOT NULL COMMENT 加班开始时间, end_time DATETIME NOT NULL COMMENT 加班结束时间, reason NVARCHAR(200) NOT NULL, FOREIGN KEY (flow_no) REFERENCES audit_flow(flow_no) );3.2 流程发起事务性操作示范以下SQL演示如何原子化地创建完整的审批流程-- 开启事务 START TRANSACTION; -- 1. 生成流程实例 INSERT INTO audit_flow(flow_no, bus_type, title, initiator_id) VALUES( CONCAT(DATE_FORMAT(NOW(), %Y%m%d%H%i%s), FLOOR(RAND()*1000)), overtime, CONCAT(员工, 10086, 的加班申请), 10086 ); -- 2. 插入业务数据 INSERT INTO overtime_application( flow_no, applicant_id, start_time, end_time, reason ) VALUES ( LAST_INSERT_ID(), 10086, 2023-08-15 19:00:00, 2023-08-15 22:00:00, 项目上线紧急支持 ); -- 3. 构建审批链从组织架构获取审批人 INSERT INTO audit_flow_detail(flow_no, auditor_id, sequence) VALUES (LAST_INSERT_ID(), 20001, 1), -- 直属主管 (LAST_INSERT_ID(), 30005, 2), -- 部门总监 (LAST_INSERT_ID(), 40022, 3); -- HRBP -- 提交事务 COMMIT;3.3 动态审批查询技巧待办列表查询根据当前用户返回待审批项SELECT f.title, f.create_time, a.start_time, a.end_time, a.reason FROM audit_flow f JOIN overtime_application a ON f.flow_no a.flow_no JOIN audit_flow_detail d ON f.flow_no d.flow_no WHERE d.auditor_id 30005 -- 当前用户ID AND d.status 1 -- 待审状态 AND f.status 1 -- 流程未结束 ORDER BY d.sequence;审批进度追踪可视化整个审批链路SELECT d.sequence, u.user_name AS auditor, CASE d.status WHEN 1 THEN 待处理 WHEN 2 THEN CONCAT(已同意(, d.comment, )) WHEN 3 THEN CONCAT(已拒绝(, d.comment, )) END AS status, d.operate_time FROM audit_flow_detail d JOIN user u ON d.auditor_id u.user_id WHERE d.flow_no 20230815193045123 ORDER BY d.sequence;4. 高级模式扩展性与性能优化4.1 审批策略配置化通过引入approval_policy表实现审批规则的可配置化CREATE TABLE approval_policy ( policy_id VARCHAR(20) PRIMARY KEY, bus_type VARCHAR(20) NOT NULL, department_id VARCHAR(20), min_amount DECIMAL(10,2) COMMENT 金额阈值, approvers JSON NOT NULL COMMENT 审批人规则 ); -- 示例规则技术部加班超过2小时需三级审批 INSERT INTO approval_policy VALUES( tech_overtime, overtime, dept_tech, 2, [ {type:role,value:tech_leader}, {type:role,value:dept_head}, {type:position,value:hrbp} ] );4.2 水平分表策略当审批数据量超过千万级时可按时间范围分表-- 按季度分表 CREATE TABLE audit_flow_detail_2023q3 ( LIKE audit_flow_detail INCLUDING INDEXES ) PARTITION BY RANGE (UNIX_TIMESTAMP(operate_time)) ( PARTITION p0 VALUES LESS THAN (UNIX_TIMESTAMP(2023-07-01)), PARTITION p1 VALUES LESS THAN (UNIX_TIMESTAMP(2023-10-01)) );4.3 历史数据归档方案-- 将已完成流程迁移到历史表 INSERT INTO audit_flow_history SELECT * FROM audit_flow WHERE status IN (2,3) AND create_time DATE_SUB(NOW(), INTERVAL 6 MONTH); -- 使用事件调度自动清理 CREATE EVENT archive_audit_data ON SCHEDULE EVERY 1 WEEK DO BEGIN -- 归档逻辑 END;在实施这套设计方案的过程中最关键的认知转变是审批本质上是一种状态机而状态机的规则应该被数据化而非代码化。当产品经理提出财务审批需要增加风控会签环节时我们不再需要紧急发布版本只需在audit_flow_detail中插入新的审批节点。这种灵活性正是现代OA系统应对快速变化业务需求的基石。
别再硬编码了！用两张核心表搞定OA多级审批（附加班申请完整SQL）
发布时间：2026/6/4 19:01:27
用两张核心表重构OA多级审批系统从硬编码到动态配置的范式转移当企业OA系统需要支持第十种审批表单时开发团队突然发现新增一个请假流程需要修改三处状态判断代码调整五处审批人获取逻辑甚至还要重写通知模版——这种场景在传统硬编码审批系统中屡见不鲜。本文将揭示如何通过主表明细表的极简设计实现可适配任意审批场景的通用流程引擎并以加班申请为例展示从表结构设计到复杂查询的完整SQL实践。1. 为什么传统审批系统必然走向重构某中型互联网公司的技术负责人曾向我展示他们的OA审批代码库在leave_approval.py中从部门主管到HR的六级审批逻辑被写成了一连串的if-else嵌套而reimbursement_approval.js里又重复实现了几乎相同的状态机转换。这种每新增一个审批类型就复制一套流程的做法导致了三个典型问题维护成本指数增长每次流程变更都需要在多处同步修改历史数据迁移困难当审批规则调整时旧数据的兼容处理成为噩梦动态调整能力缺失临时增加审批层级需要发布新版本-- 典型硬编码审批查询示例请假流程专用 SELECT * FROM leave_application WHERE department_id 5 AND status IN (pending_director, pending_hr);相比之下基于核心表的动态审批系统通过流程配置数据化解决了这些问题。其本质是将审批规则从代码迁移到数据库使流程变更成为数据操作而非代码修改。2. 核心表设计的黄金法则最小化与扩展性2.1 主表设计流程实例容器audit_flow表作为所有审批流程的根容器只需关注流程实例本身的元信息与具体业务类型解耦字段名类型说明设计要点flow_noVARCHAR(50)唯一流程编号前缀包含日期(yyyyMMdd)便于归档bus_typeVARCHAR(20)业务类型标识符对应各业务表如overtimetitleNVARCHAR(50)动态标题如张三的加班申请支持模板字符串拼接initiator_idVARCHAR(20)发起人ID关联用户体系statusTINYINT全局状态(1待审/2通过/3驳回)使用状态码而非字符串-- 主表创建SQLMySQL语法 CREATE TABLE audit_flow ( flow_no VARCHAR(50) PRIMARY KEY, bus_type VARCHAR(20) NOT NULL COMMENT 业务类型代码, title NVARCHAR(50) NOT NULL COMMENT 流程标题, initiator_id VARCHAR(20) NOT NULL COMMENT 发起人ID, status TINYINT DEFAULT 1 NOT NULL COMMENT 1待审 2通过 3驳回, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;2.2 明细表设计动态审批链audit_flow_detail表的核心创新在于用数据驱动替代硬编码审批链每条记录代表一个审批环节字段名类型说明关键设计idBIGINT自增主键无业务意义flow_noVARCHAR(50)关联主表级联删除auditor_idVARCHAR(20)审批人ID支持角色ID或具体用户IDsequenceSMALLINT审批顺序实现会签/或签逻辑statusTINYINT环节状态(1待审/2通过/3驳回)独立于主表状态commentNVARCHAR(500)审批意见支持富文本-- 明细表创建SQL含索引优化 CREATE TABLE audit_flow_detail ( id BIGINT PRIMARY KEY AUTO_INCREMENT, flow_no VARCHAR(50) NOT NULL, auditor_id VARCHAR(20) NOT NULL, sequence SMALLINT NOT NULL COMMENT 审批顺序, status TINYINT DEFAULT 1 NOT NULL COMMENT 1待审 2通过 3驳回, comment NVARCHAR(500), operate_time DATETIME, FOREIGN KEY (flow_no) REFERENCES audit_flow(flow_no) ON DELETE CASCADE, INDEX idx_auditor_status (auditor_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;设计验证当需要实现部门主管→财务→CEO的三级审批时只需向明细表插入三条记录通过sequence字段控制审批顺序无需修改任何代码。3. 实战加班申请的全流程SQL实现3.1 业务表设计范式以加班申请为例业务表只需关注业务属性流程控制完全交给核心表CREATE TABLE overtime_application ( flow_no VARCHAR(50) PRIMARY KEY, applicant_id VARCHAR(20) NOT NULL, start_time DATETIME NOT NULL COMMENT 加班开始时间, end_time DATETIME NOT NULL COMMENT 加班结束时间, reason NVARCHAR(200) NOT NULL, FOREIGN KEY (flow_no) REFERENCES audit_flow(flow_no) );3.2 流程发起事务性操作示范以下SQL演示如何原子化地创建完整的审批流程-- 开启事务 START TRANSACTION; -- 1. 生成流程实例 INSERT INTO audit_flow(flow_no, bus_type, title, initiator_id) VALUES( CONCAT(DATE_FORMAT(NOW(), %Y%m%d%H%i%s), FLOOR(RAND()*1000)), overtime, CONCAT(员工, 10086, 的加班申请), 10086 ); -- 2. 插入业务数据 INSERT INTO overtime_application( flow_no, applicant_id, start_time, end_time, reason ) VALUES ( LAST_INSERT_ID(), 10086, 2023-08-15 19:00:00, 2023-08-15 22:00:00, 项目上线紧急支持 ); -- 3. 构建审批链从组织架构获取审批人 INSERT INTO audit_flow_detail(flow_no, auditor_id, sequence) VALUES (LAST_INSERT_ID(), 20001, 1), -- 直属主管 (LAST_INSERT_ID(), 30005, 2), -- 部门总监 (LAST_INSERT_ID(), 40022, 3); -- HRBP -- 提交事务 COMMIT;3.3 动态审批查询技巧待办列表查询根据当前用户返回待审批项SELECT f.title, f.create_time, a.start_time, a.end_time, a.reason FROM audit_flow f JOIN overtime_application a ON f.flow_no a.flow_no JOIN audit_flow_detail d ON f.flow_no d.flow_no WHERE d.auditor_id 30005 -- 当前用户ID AND d.status 1 -- 待审状态 AND f.status 1 -- 流程未结束 ORDER BY d.sequence;审批进度追踪可视化整个审批链路SELECT d.sequence, u.user_name AS auditor, CASE d.status WHEN 1 THEN 待处理 WHEN 2 THEN CONCAT(已同意(, d.comment, )) WHEN 3 THEN CONCAT(已拒绝(, d.comment, )) END AS status, d.operate_time FROM audit_flow_detail d JOIN user u ON d.auditor_id u.user_id WHERE d.flow_no 20230815193045123 ORDER BY d.sequence;4. 高级模式扩展性与性能优化4.1 审批策略配置化通过引入approval_policy表实现审批规则的可配置化CREATE TABLE approval_policy ( policy_id VARCHAR(20) PRIMARY KEY, bus_type VARCHAR(20) NOT NULL, department_id VARCHAR(20), min_amount DECIMAL(10,2) COMMENT 金额阈值, approvers JSON NOT NULL COMMENT 审批人规则 ); -- 示例规则技术部加班超过2小时需三级审批 INSERT INTO approval_policy VALUES( tech_overtime, overtime, dept_tech, 2, [ {type:role,value:tech_leader}, {type:role,value:dept_head}, {type:position,value:hrbp} ] );4.2 水平分表策略当审批数据量超过千万级时可按时间范围分表-- 按季度分表 CREATE TABLE audit_flow_detail_2023q3 ( LIKE audit_flow_detail INCLUDING INDEXES ) PARTITION BY RANGE (UNIX_TIMESTAMP(operate_time)) ( PARTITION p0 VALUES LESS THAN (UNIX_TIMESTAMP(2023-07-01)), PARTITION p1 VALUES LESS THAN (UNIX_TIMESTAMP(2023-10-01)) );4.3 历史数据归档方案-- 将已完成流程迁移到历史表 INSERT INTO audit_flow_history SELECT * FROM audit_flow WHERE status IN (2,3) AND create_time DATE_SUB(NOW(), INTERVAL 6 MONTH); -- 使用事件调度自动清理 CREATE EVENT archive_audit_data ON SCHEDULE EVERY 1 WEEK DO BEGIN -- 归档逻辑 END;在实施这套设计方案的过程中最关键的认知转变是审批本质上是一种状态机而状态机的规则应该被数据化而非代码化。当产品经理提出财务审批需要增加风控会签环节时我们不再需要紧急发布版本只需在audit_flow_detail中插入新的审批节点。这种灵活性正是现代OA系统应对快速变化业务需求的基石。
