企业官网建设流程全解析

简介：这份《OA办公系统大数据库设计》文档面向OA办公自动化管理系统的设计、开发、验收、评审与测试人员，以及客户方市场与开发人员，用于指导数据库从数据分析到物理建模的完整落地。文档以MSSQL SERVER 2008 R2为数据库平台，数据库名为OASYSDB，内容涵盖引言、数据字典设计、数据库设计三大板块，并细分为系统物理结构设计、表设计、表间关联设计、存储过程设计、触发器设计与Job设计等模块。数据字典部分以卡片形式逐项定义人员编号、姓名、性别、出生年月、部门、岗位、婚姻状况、联系电话、入职日期、电子邮箱、家庭地址、照片、密码、工资等数据项的类型、长度与位置，并给出个人信息、个人可修改信息、密码修改信息等数据流组合关系，便于读者理解字段约束与业务含义。资源包为1个doc文档，大小约211KB，结构清晰、目录完整，已有144人学习。适合需要参考OA系统数据库建模、编写数据字典或搭建表结构与存储过程的开发者对照使用。

1. OA 办公系统数据库设计：为什么“能跑”和“能撑三年”是两回事

接手一个 OA 办公系统时，大多数人第一反应是画 ER 图、建表、写外键，然后跑通登录和审批流就算完事。但真正让一线工程师头疼的，从来不是“能不能跑”，而是上线半年后：员工信息表膨胀到千万级、审批记录查询越来越慢、组织架构调整一次要改十几张表、离职员工的数据删不干净还留着权限。OA 办公系统的数据库设计，本质上是在给一家公司的组织行为建模——人、部门、角色、权限、流程、表单、附件、日志，每一样都会随时间生长和变形。这篇笔记面向的是正在做或准备重构 OA 系统的后端和 DBA，我会把用户信息表、组织架构、权限模型、流程引擎数据、附件与日志这几块拆开讲，给出可直接抄的表结构和参数，也把踩过的坑摆出来。数据库设计不是一次性作业，它决定了这套 OA 三年后是继续迭代还是推倒重来。

2. 用户信息表与组织架构：OA 数据库设计的第一块地基

2.1 用户信息表为什么不能照搬“博客系统”那套

热搜里“第1关:数据库表设计 - 用户信息表”和“博客系统 - 数据库设计”经常被拿来当模板，但 OA 的用户表和博客的用户表根本不是一回事。博客系统一个用户就是一个人，字段无非 id、username、password、email、avatar。OA 里一个“用户”要同时承载：登录凭证、员工档案、组织归属、岗位角色、上级关系、在职状态、多端登录设备。如果把这些全塞进一张 user 表，字段会超过 40 个，而且组织架构一变就要改表结构。

我一般会把用户拆成三张表：sys_user（登录与账号状态）、sys_employee（员工档案与任职信息）、sys_user_auth（第三方登录与设备绑定）。这样账号可以停用但档案保留，员工离职后账号冻结、档案归档，互不影响。

-- 账号表：只放登录相关，字段尽量少，更新频率低 CREATE TABLE sys_user ( user_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户ID', username VARCHAR(64) NOT NULL COMMENT '登录名，全局唯一', password_hash VARCHAR(128) NOT NULL COMMENT 'bcrypt 后的密码', salt VARCHAR(32) NOT NULL COMMENT '密码盐', status TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0停用 2锁定', last_login_at DATETIME DEFAULT NULL COMMENT '最后登录时间', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (user_id), UNIQUE KEY uk_username (username) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='账号表';

逻辑说明：username加唯一索引是必须的，OA 里经常出现同名员工，登录名必须唯一。status用 tinyint 而不是布尔，因为后面大概率会加“锁定”“待激活”等状态。password_hash长度给 128，bcrypt 输出 60 字符，留余量给未来换算法。参数上，utf8mb4是硬要求，员工姓名里可能有生僻字，utf8 三字节存不下。

2.2 组织架构表的三种存法，我为什么选“路径枚举 + 邻接表”

组织架构是 OA 数据库设计里最容易翻车的地方。常见三种方案：邻接表（parent_id）、路径枚举（path 字段存 /1/3/7/）、嵌套集（左右值）。邻接表查直接下级快，查所有下级要递归；路径枚举查所有下级一条 LIKE 就够，但移动部门要批量更新 path；嵌套集查询快但插入和移动代价高，OA 里组织调整频繁，不划算。

我的做法是邻接表 + 路径枚举冗余：parent_id保证单层查询和完整性，path存物化路径用于快速查子树。移动部门时用一条 UPDATE 批量改 path 前缀。

CREATE TABLE sys_dept ( dept_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, parent_id BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '父部门，0为根', dept_name VARCHAR(128) NOT NULL, dept_path VARCHAR(512) NOT NULL DEFAULT '' COMMENT '物化路径 /1/3/7/', dept_level TINYINT UNSIGNED NOT NULL DEFAULT 1 COMMENT '层级，根为1', sort_order INT NOT NULL DEFAULT 0 COMMENT '同级排序', leader_id BIGINT UNSIGNED DEFAULT NULL COMMENT '部门负责人', status TINYINT NOT NULL DEFAULT 1, PRIMARY KEY (dept_id), KEY idx_parent (parent_id), KEY idx_path (dept_path(191)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='部门表';

逻辑说明：dept_path用/开头结尾，查子树时WHERE dept_path LIKE '/1/3/%'能命中索引前缀。dept_level冗余存层级，避免每次数斜杠。idx_path前缀长度 191 是因为 utf8mb4 下索引长度限制，路径本身是数字和斜杠，实际不会超。

移动部门的批量更新：

-- 把部门 7 及其所有下级从 /1/3/7/ 移到 /1/5/7/ UPDATE sys_dept SET dept_path = REPLACE(dept_path, '/1/3/7/', '/1/5/7/'), dept_level = dept_level - 1 WHERE dept_path LIKE '/1/3/7/%';

参数说明：REPLACE只替换前缀部分，因为 path 里部门 ID 不会重复出现。dept_level的调整量取决于新旧父级层级差，这里假设从 3 级移到 2 级。这个操作要在事务里做，并且移动前先校验目标父部门不是自己的子孙，否则会形成环。

2.3 用户与部门的多对多：主部门与兼职部门要分开

一个员工可能同时属于多个部门（主部门 + 兼职），但权限和审批流通常只认主部门。我见过有人直接在sys_employee里加dept_id，结果兼职场景一来就加字段，加到第四五个部门时表就废了。

正确做法是中间表sys_employee_dept，用is_primary标记主部门，并且加唯一约束保证一个员工只有一个主部门。

CREATE TABLE sys_employee_dept ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, employee_id BIGINT UNSIGNED NOT NULL, dept_id BIGINT UNSIGNED NOT NULL, is_primary TINYINT NOT NULL DEFAULT 0 COMMENT '1主部门 0兼职', join_date DATE NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_emp_dept (employee_id, dept_id), KEY idx_dept (dept_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='员工部门关系';

逻辑说明：uk_emp_dept防止同一员工重复加入同一部门。主部门唯一性用应用层 + 定时校验保证，MySQL 没有部分唯一索引，硬要在数据库层做只能加触发器，我一般不在数据库里做业务约束，留给服务层。

提示：组织架构表上线前一定要做一次“环检测”脚本，把所有部门的 parent_id 链走一遍，确认没有 A→B→A 的环。我见过因为手工导入数据形成环，导致递归查询直接栈溢出。

3. 权限模型与流程引擎数据：OA 数据库设计里最容易过度设计的两块

3.1 RBAC 够用，但别把角色和岗位混成一张表

权限模型上，OA 系统 90% 的场景 RBAC（用户-角色-权限）就够。但很多人把“角色”和“岗位”混在一起：角色是权限集合（如“审批人”“财务”），岗位是组织属性（如“部门经理”“总监”）。一个人可以同时是“部门经理”岗位和“审批人”角色，但这两者来源不同、变更频率不同。

我一般分四张表：sys_role（角色）、sys_permission（权限点）、sys_role_permission（角色权限）、sys_user_role（用户角色）。岗位单独放sys_position，和角色通过sys_position_role关联，实现“岗位自动带角色”。

CREATE TABLE sys_role ( role_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, role_code VARCHAR(64) NOT NULL COMMENT '角色编码，如 APPROVER', role_name VARCHAR(64) NOT NULL, data_scope TINYINT NOT NULL DEFAULT 1 COMMENT '1本人 2本部门 3本部门及下级 4全部', status TINYINT NOT NULL DEFAULT 1, PRIMARY KEY (role_id), UNIQUE KEY uk_role_code (role_code) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='角色表';

参数说明：data_scope是 OA 权限里最关键的字段，决定这个角色能看到哪些数据。很多 OA 的“数据权限”做得很粗糙，就是因为没有在角色层面定义数据范围，而是散落在各个查询里。把 data_scope 定在角色上，查询时统一拼 SQL 条件，维护成本低很多。

权限点表sys_permission建议用perm_code如oa:approve:create，前端按钮和后端接口都用同一套编码，避免“前端隐藏了按钮但接口还能调”的经典漏洞。

3.2 流程引擎数据：别自己造工作流表，除非你打算维护三年

OA 的核心是审批流。我见过太多团队一开始自己设计flow_instance、flow_node、flow_task三张表，跑到第二年发现要支持会签、或签、加签、退回、撤回、超时自动通过，表结构改了十几版，历史数据迁移到崩溃。

常见做法是：如果流程不复杂（线性审批、单人审批），自建三张表够用；如果涉及会签、条件分支、子流程，直接上成熟的工作流引擎（如 Flowable、Activiti），OA 业务表只存业务数据，流程数据交给引擎。自建的话，核心表至少要有：

CREATE TABLE flow_instance ( instance_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, biz_type VARCHAR(64) NOT NULL COMMENT '业务类型，如 LEAVE', biz_id BIGINT UNSIGNED NOT NULL COMMENT '业务单据ID', flow_status TINYINT NOT NULL DEFAULT 0 COMMENT '0草稿 1审批中 2通过 3驳回 4撤回', current_node VARCHAR(64) DEFAULT NULL COMMENT '当前节点编码', initiator_id BIGINT UNSIGNED NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, finished_at DATETIME DEFAULT NULL, PRIMARY KEY (instance_id), KEY idx_biz (biz_type, biz_id), KEY idx_initiator (initiator_id, flow_status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='流程实例';

逻辑说明：biz_type + biz_id联合索引让业务单据能反查流程状态。flow_status和initiator_id的联合索引用于“我发起的审批”列表页，这是 OA 里访问最频繁的查询之一。

流程任务表flow_task要记录assignee_id、node_code、task_status、deadline，并且加KEY idx_assignee_status (assignee_id, task_status)，否则“待我审批”列表在任务量大了之后会全表扫描。

注意：流程实例和业务单据的状态一致性是 OA 里最经典的坑。审批通过了但业务表没更新，或者业务表更新了流程还停在审批中。我的做法是流程引擎回调业务方时用本地消息表 + 重试，不依赖单次调用成功。

4. 附件、日志与数据量增长：OA 数据库设计里最容易被低估的部分

4.1 附件表不要存文件内容，但一定要存文件指纹

OA 里附件量增长极快，一个审批单可能带五六个附件，一年下来附件表几百万行很正常。附件表只存元数据：文件名、大小、MIME、存储路径、上传人、业务关联。文件内容放对象存储或文件服务器，数据库里只存 URL 或 key。

但有一个字段我强烈建议加：file_hash（SHA-256）。用途有两个：秒传（同一文件重复上传直接复用）和去重（离职员工批量导出的附件里大量重复）。没有这个字段，存储成本会悄悄翻倍。

CREATE TABLE sys_attachment ( attach_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, biz_type VARCHAR(64) NOT NULL, biz_id BIGINT UNSIGNED NOT NULL, file_name VARCHAR(255) NOT NULL, file_size BIGINT UNSIGNED NOT NULL COMMENT '字节', file_hash CHAR(64) NOT NULL COMMENT 'SHA-256', storage_key VARCHAR(512) NOT NULL COMMENT '对象存储key', uploader_id BIGINT UNSIGNED NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (attach_id), KEY idx_biz (biz_type, biz_id), KEY idx_hash (file_hash) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='附件表';

参数说明：file_hash用 CHAR(64) 存十六进制 SHA-256，比 VARCHAR 省空间且定长索引效率高。idx_hash用于秒传查询。storage_key给 512 长度，因为对象存储的 key 可能包含多层路径和日期。

4.2 操作日志表的分区与归档策略

OA 的操作日志（谁在什么时候改了哪个单子）是审计刚需，但也是增长最快的表。一天一万条操作，一年就是三百多万行，三年上千万。单表千万级查询还能撑，但写入和备份会变慢。

我的做法：日志表按created_at做 RANGE 分区，按月分区，保留最近 12 个月在线，更早的归档到历史库或冷存储。

CREATE TABLE sys_oper_log ( log_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, user_id BIGINT UNSIGNED NOT NULL, module VARCHAR(64) NOT NULL, action VARCHAR(64) NOT NULL, biz_id BIGINT UNSIGNED DEFAULT NULL, detail JSON DEFAULT NULL COMMENT '变更前后快照', ip VARCHAR(45) DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (log_id, created_at), KEY idx_user_time (user_id, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 PARTITION BY RANGE (TO_DAYS(created_at)) ( PARTITION p202501 VALUES LESS THAN (TO_DAYS('2025-02-01')), PARTITION p202502 VALUES LESS THAN (TO_DAYS('2025-03-01')), PARTITION p202503 VALUES LESS THAN (TO_DAYS('2025-04-01')) );

逻辑说明：分区表的主键必须包含分区键，所以主键是(log_id, created_at)。detail用 JSON 存变更快照，比给每个字段建一列灵活得多，MySQL 5.7+ 支持 JSON 后这是 OA 日志的标配。归档时用ALTER TABLE ... DROP PARTITION秒删，比 DELETE 快几个数量级，而且不会产生大量 undo。

参数说明：分区不要建太多，按月分区一年 12 个，三年 36 个，超过 50 个分区后优化器选择分区的开销会上升。归档策略建议在业务低峰期用脚本自动执行，先EXCHANGE PARTITION到临时表再导出。

4.3 数据量预估与索引设计：上线前必须做的一张表

OA 数据库设计最怕“上线时没数据，上线后爆炸”。我一般会在设计阶段做一张容量预估表，把每张表的日增行数、年增行数、主要查询、索引列写清楚，然后据此决定哪些表要分区、哪些查询要加覆盖索引。

这张表不用写进代码，但设计评审时必须过一遍。没有它，索引就是拍脑袋加的，上线后慢查询日志里全是全表扫描。

5. 避坑与排查：OA 数据库设计里那些血泪经验

5.1 现象：审批列表页越翻越慢，第一页 200ms，第十页 3 秒

原因：用了LIMIT offset, size深分页，offset 越大扫描行数越多。OA 的待办列表通常按时间倒序，翻到后面 offset 可能上万。

解决：改成游标分页，用上一页最后一条的task_id或created_at作为锚点。WHERE assignee_id = ? AND task_id < ? ORDER BY task_id DESC LIMIT 20。配合(assignee_id, task_id)联合索引，任何页都是毫秒级。

5.2 现象：组织架构调整后，部分员工看不到自己部门的单据

原因：sys_employee_dept里主部门标记is_primary没有同步更新，或者数据权限查询用的是缓存里的旧部门树。

解决：组织调整必须在一个事务里完成部门表更新 + 员工部门关系更新 + 清理权限缓存。我一般会在部门表加一个version字段，每次调整自增，权限服务缓存 key 带上 version，version 变了缓存自然失效。

5.3 现象：流程审批通过后，业务单据状态没变，用户重复提交

原因：流程引擎回调和业务更新不在同一事务，回调失败后没有重试，或者重试时业务方已经处理过导致重复。

解决：业务方更新接口必须做幂等，用flow_instance_id + node_code做唯一键，重复请求直接返回成功。同时流程引擎侧用本地消息表记录回调状态，定时任务扫描失败记录重试。

5.4 现象：附件上传后文件名乱码，下载时打不开

原因：数据库连接字符集不是 utf8mb4，或者对象存储的 key 用了原始文件名导致特殊字符问题。

解决：连接串强制characterEncoding=utf8mb4，存储 key 用 UUID 或雪花 ID，原始文件名只存在数据库file_name字段里。下载时从数据库取文件名设置 Content-Disposition。

5.5 现象：日志表越来越大，备份时间从 10 分钟涨到 2 小时

原因：单表没有分区，DELETE 历史数据产生大量 binlog 和 undo，备份时全表扫描。

解决：按前面说的 RANGE 分区，归档用 DROP PARTITION。如果已经是大表，用pt-archiver工具分批归档，每批 1000 行，间隔 0.5 秒，避免主从延迟。

6. 进阶：用“影子表”做 OA 数据库的在线变更验证

OA 系统一旦上线，改表结构就是高风险操作。加一个字段可能锁表几分钟，改一个索引可能让某个查询突然走错执行计划。我后来养成了一个习惯：任何 DDL 变更前，先在影子表上跑一遍。

具体做法：用CREATE TABLE sys_user_shadow LIKE sys_user复制结构，把生产数据导出最近一个月到影子表，在影子表上执行 DDL 和典型查询，用EXPLAIN对比执行计划。确认没问题再上生产，并且用pt-online-schema-change或 MySQL 8.0 的ALGORITHM=INPLACE减少锁表时间。

-- 在影子表上验证加索引后的执行计划 EXPLAIN SELECT task_id, biz_type, biz_id FROM flow_task_shadow WHERE assignee_id = 10086 AND task_status = 0 ORDER BY created_at DESC LIMIT 20;

逻辑说明：重点看type是不是ref或range，rows是不是在预期范围内，Extra里有没有Using filesort。如果影子表上走了索引而生产没走，大概率是统计信息不准，ANALYZE TABLE一下。

另一个技巧是给关键表加updated_at字段并建索引，用于增量同步到影子表。每次变更前同步最近数据，验证完直接删影子表，成本很低。

我自己的习惯是：任何 OA 数据库的 DDL 变更，没有在影子表上跑过EXPLAIN和至少 10 万行数据的查询测试，绝不上生产。这个习惯帮我挡掉了至少三次会导致全表扫描的索引变更。数据库设计这件事，后悔药很贵，影子表是最便宜的保险。希望帮到你。

本文还有配套的精品资源，点击获取