简介泛微OA E9表结构.zip 是一份面向泛微OA E9系统管理员、实施工程师及二次开发人员的数据库表结构参考包。E9系统的组织管理、流程审批、文档管理、权限控制等核心模块都建立在底层数据表之上。资源聚焦用户信息表、流程定义表、任务实例表、文档管理表、权限角色表、组织结构表、日程管理表及通讯录表等主要表结构能帮助读者快速理解数据模型并为权限策略定制、审批流调整、知识库优化提供直接依据。压缩包体积约3.67MB以SQL脚本或数据库设计文档形式呈现属于轻量型参考文件便于下载和查阅。目前已有289人学习使用适合具备一定数据库基础、需要深入掌握E9业务逻辑的读者。通过阅读这些脚本或文档可以掌握各表字段、主外键关系及典型关联为后续系统维护、性能调优与数据迁移提供宝贵参考。1. E9 泛微 OA 表结构这张数据库地图决定二次开发的下限做泛微 E9 二次开发的人迟早会撞到同一个问题流程数据存在哪张表人员档案和账号是不是同一个表文档版本怎么查。E9 泛微 OA 的系统逻辑很完整但前端界面看不出来的全压在数据库表结构里。这份“E9表结构.zip”就是把它所有数据库表的字段、类型、主键、外键关系摊开给你看的一张地图做集成、做权限调整、做历史数据迁移都绕不开它。适合三类人接 E9 的集成开发、做 OA 运维的实施人员、以及从 E8 升到 E9 需要快速对齐表差异的熟手。有了这张图你至少不用再靠猜。2. 先看懂数据模型用户、组织、流程、文档这几类表是怎么咬合的2.1 组织与用户账号、人员、组织三张表先分清我刚接触泛微 E9 时犯过一个低级错误以为登录账号和人员信息在同一个表里。实际拆开表结构才能发现账号体系、人员档案、组织架构是分开落库的它们之间靠字段关联但未必都有严格的外键约束。这类资源的压缩包里人员相关的表通常集中在 hrm 或 res 前缀下E9 资源模型调整后部分命名有变化以解压后的文件为准常见角色有人员主表一条记录对应一个人包含姓名、工号、性别、学历、入职日期等自然属性账号表存登录名、密码哈希、状态、关联人员 ID负责认证组织表部门、岗位、分部层级人员通过部门 ID、岗位 ID 关联到组织。我一般拿到表结构会先跑一条 SQL 把这几类表拉出来确认当前库里到底有哪些前缀再决定业务查询怎么写。以 SQL Server 为例SELECT t.name AS table_name FROM sys.tables t WHERE t.name LIKE hrm% OR t.name LIKE res% OR t.name LIKE org% ORDER BY t.name;这段代码的逻辑是先限定只查系统表元数据用 LIKE 过滤出人力、资源、组织相关表按名字排序后手动识别主表和关联表。注意别以为 LIKE hrm% 就万事大吉E9 里部分人员表在 res 前缀下两条过滤条件都要带上。参数说明sys.tables 是 SQL Server 的系统视图t.name 是表名LIKE 后面跟的是你要找的前缀组。2.2 流程与任务流程定义和流程实例是两套东西这是 E9 表结构里最容易被误解的地方。流程定义表存的是“审批流长什么样”比如流程名称、节点顺序、参与人规则而流程实例表存的是“某个员工发起的那次具体的审批”比如流程 ID、发起人、状态、创建时间。如果你把流程定义表当成流程数据来查大概率什么业务记录都查不到。E9 中表名前缀一般是 workflow下表名大致能对上角色表定位典型字段主要用途流程定义主表流程 ID、流程名称、分类查流程版本和节点配置流程节点表节点 ID、操作类型、参与人规则做节点级分析流程实例主表requestid、发起人、状态、创建时间查所有实际发起的审批流程当前处理人表requestid、当前处理人、接收时间查待办和处理轨迹用下面的脚本可以快速把流程相关表都找出来SELECT t.name AS table_name, t.create_date FROM sys.tables t WHERE t.name LIKE workflow% ORDER BY t.name;这里的 t.create_date 是建表时间用来判断哪些表是后来自定义或补丁生成的业务开发时优先看标准表。逻辑说明只按前缀过滤会把工作流中间临时表也带出来建议建表时间排个序能帮你区分标准表与系统运行产生的临时表。2.3 文档与知识主表存元数据明细表存版本轨迹文档管理在 E9 里也不是一张表解决的。从表结构看通常有文档主表和文档明细表两套主表存文档 ID、标题、创建人、创建时间、文档分类这些稳定的元数据明细表存版本号、修改时间、修改人、文件路径等每次变更产生的记录。这意味着查“最新版本文档”不能只查主表要靠明细表按版本号倒序取第一条。多版本混在一起时主表和明细表是一对多关系做列表分页查询尤其要小心重复行。先看字段清单再写查询是这种场景的标准做法SELECT c.name AS column_name, ty.name AS data_type, c.max_length FROM sys.columns c JOIN sys.types ty ON c.user_type_id ty.user_type_id WHERE c.object_id OBJECT_ID(docmain) ORDER BY c.column_id;这段代码的背景是你对 docmain 这张表的结构不确定先列出它的所有字段名、类型和长度。OBJECT_ID 返回表对象 IDsys.columns 只带出这张表的列。data_type 和 max_length 用于判断哪些字段是 ID、哪些是时间、哪些可能是文件路径。实际拿到的脚本里文档主表未必叫 docmain以文件里的建表语句为准。2.4 权限与角色表结构里藏着你的权限设计边界权限角色表在 E9 里通常以 sec 前缀为主字段上能看到角色 ID、资源 ID、操作权限位、数据范围等。所谓操作权限位就是同一个角色对某菜单有查看、编辑、删除的粒度控制字段里往往用多个状态字段或位标志来表达。我从这类表里得到的一个实用结论如果你要做一个“按部门隔离数据”的集成接口不要只盯着角色表还要看数据权限范围字段。一旦范围字段是 1、2、3 这类枚举值必须在表结构文档里查对应含义猜错一个值数据可能全透传出去。3. 把表结构文件当字典读三种查询吃透数据模型3.1 全库表清单核对先数一数总量再找核心表解压“E9表结构.zip”之后我建议第一步不是看某张表而是拉全库表清单确认文件里的表数量和你目标环境一致。常见的文件形式是 SQL 脚本里面可能建库、建表、插注释都混在一起直接全量执行有风险。先把结构理清楚再决定一次执行还是分批执行。当文件是建表脚本时你可以用字符串搜索把 CREATE TABLE 都提出来统计表数量grep -i ^CREATE TABLE E9_tables.sql | wc -l如果是 Windows 环境用 PowerShell 也一样能实现。这里的 grep 区分大小写开关 -i 是避免漏掉非标准写法wc -l 统计行数也就是表数量。拿到总数后与文件列表预览对比如果数字对不上说明脚本里可能有临时表或者重复建表语句要回头检查。文件里注明表数量的话尽量以文件说明为准。3.2 字段级元数据查询字段名、类型、默认值与必填只看表名远不够二次开发问的最多是“这个字段能不能为空、默认值是什么、存的是 ID 还是字符串”。SQL Server 上我常用信息架构视图直接查比翻脚本快得多SELECT t.name AS table_name, c.name AS column_name, ty.name AS data_type, c.max_length, c.is_nullable, c.default_object_id FROM sys.tables t JOIN sys.columns c ON t.object_id c.object_id JOIN sys.types ty ON c.user_type_id ty.user_type_id WHERE t.name workflow_requestbase ORDER BY c.column_id;这段查询把 workflow_requestbase 的每个字段、类型、长度、是否可空和默认值约束都列出来。c.default_object_id 是默认约束的对象 ID不为 0 说明这个字段有默认值。你要是发现一张表全字段都允许为空那多半是历史兼容表写入业务表时不要指望数据库帮你做约束业务侧要自己校验。3.3 主外键关系反查系统没有外键时你要自己找血缘老版本泛微体系里部分表之间不建物理外键只靠命名规范和业务逻辑关联。这对运维来说是“自由”对开发来说是“坑”。你可以用系统外键视图把已知关系一次性拉出来再人工查缺补漏SELECT fk.name AS fk_name, tp.name AS parent_table, cp.name AS parent_column, ref.name AS referenced_table, cr.name AS referenced_column FROM sys.foreign_keys fk JOIN sys.foreign_key_columns fkc ON fk.object_id fkc.constraint_object_id JOIN sys.tables tp ON fk.parent_object_id tp.object_id JOIN sys.columns cp ON fkc.parent_object_id cp.object_id AND fkc.parent_column_id cp.column_id JOIN sys.tables ref ON fk.referenced_object_id ref.object_id JOIN sys.columns cr ON fkc.referenced_object_id cr.object_id AND fkc.referenced_column_id cr.column_id WHERE ref.name workflow_requestbase ORDER BY parent_table;代码逻辑是先拿外键元数据join 三张系统视图把父表、父列、引用表、引用列都投影出来最后用 WHERE 筛选引用表。结果里如果空无一物说明流程实例表没有物理外键你要回到业务关系上按字段名手动补血缘关系。我一般会再跑一条查询把 workflow_requestbase 里所有含 requestid 或 id 的字段列出来辅助判断。3.4 Oracle 环境的差异点对象名大小写与注释来源如果你所在公司用的是 Oracle上述 SQL Server 写法要整体换掉。表结构脚本是 SQL 脚本时Oracle 里表名、字段名默认大写查询时写小写表名会直接报“表或视图不存在”。我常用的替代查询是 all_tab_columns 配合 owner先确认当前用户能看到多少表SELECT table_name, column_name, data_type, data_length, nullable FROM all_tab_columns WHERE owner OA_USER AND table_name WORKFLOW_REQUESTBASE ORDER BY column_id;核心变化在数据字典视图all_tab_columns 而不是 sys.columns。data_length 表示字段最大字节长度注意它是字节不是字符存中文时要再乘字符集倍率。另外Oracle 里字段注释需要单独从 all_col_comments 取不会像 SQL Server 的扩展属性那么方便。执行前先确认 owner否则连注释都查不到。4. 开发落地从表结构到业务查询的几个实用脚本4.1 场景一读取人员信息并关联部门表结构看懂了最终要落成可执行的查询。常见的第一个需求就是“根据登录名拿人员信息顺便关联部门名称”。我一般先确认人员主表的字段命名然后用一个 LEFT JOIN 把组织信息带出来SELECT r.id, r.loginid, r.lastname AS user_name, r.departmentid, d.departmentname FROM hrmresource r LEFT JOIN orgdepartment d ON r.departmentid d.id WHERE r.loginid zhangsan;hrmresource 在 E9 的很多实施环境里仍是人员主表如果你解压的脚本里不是这个名字替换成对应人员表即可。LEFT JOIN 保证即使部门已经不存在人员记录也能查出来不会因关联不到部门而整行丢失。loginid 唯一性的前提是账号未做过合并做集成前可以先确认没有重复值。4.2 场景二查询流程实例与当前处理人第二个高频场景是把“某人发起的所有流程”和“当前停留在哪个节点”一次性查出来。这里要特别留意流程实例与当前处理人表的关联关系因为一个流程实例可能对应多个待办节点。SELECT rb.requestid, rb.requestname, rb.createrid, rb.createdate, rb.createtime, co.userid AS current_operator, co.operatortype FROM workflow_requestbase rb LEFT JOIN workflow_currentoperator co ON rb.requestid co.requestid WHERE rb.createrid 1001 AND co.operatortype 0 ORDER BY rb.createdate DESC, rb.createtime DESC;逻辑说明先从流程实例主表拿基本信息再关联当前处理人表用 operatortype 过滤掉角色类型的操作者只保留人员类型。参数里 0 是否表示人员类型要看表结构文件里的枚举说明不要想当然。这里的 ORDER BY 按日期和时间双字段排序是因为 createdate 和 createtime 拆成了两个字段。4.3 场景三按分类统计流程数量验证表数据质量这类脚本只做一件事按流程分类统计不同流程的发起量用来验证表结构文件与实际业务数据是否对得上。分类字段可能在 workflow_requestbase 里也可能在 workflow_base 里需要提前确认。SELECT wb.workflowname, COUNT(rb.requestid) AS request_count, MIN(rb.createdate) AS first_date, MAX(rb.createdate) AS last_date FROM workflow_requestbase rb LEFT JOIN workflow_base wb ON rb.workflowid wb.workflowid GROUP BY wb.workflowname ORDER BY request_count DESC;MIN 和 MAX 用来判断数据时间跨度如果时间跨度为零说明这张表可能被定期清理过不适合做长期趋势统计。GROUP BY 后如果发现某个流程名下有几千条但另一张关联表里没有定义那就是表结构对应关系出了问题要回到文件里的建表语句二次核对。4.4 场景四文档元数据与创建人信息文档查询比流程简单但版本字段是易错点。只查主表会漏掉“同一文档多个版本”的记录需要先理解这张表的粒度SELECT docid, docname, doccreater, doccreatedate, doclastmodifier, doclastmodifydate, docversion FROM docmain WHERE docversion ( SELECT MAX(docversion) FROM docmain d2 WHERE d2.docid docmain.docid );这段代码的用途是取每个文档的最新版本。子查询按同名文档找最大版本号外层过滤只保留最新那条。问题在于如果脚本里没有 docversion 这个字段需要换成版本 ID 或修改时间来判断。文档表在不同版本的系统中列名差异很大我建议先跑一个SELECT TOP 10 * FROM docmain看实际字段再套用上面的结构。5. E9 表结构落地避坑五条常见翻车记录5.1 翻车一拿“当前表”查历史数据结果天然不准现象某次统计“上个月离职人数”直接查人员主表按离职日期过滤结果少了三成。原因人员主表存的是当前快照人员离职后部分记录会迁移到历史表或者主表里的离职日期被更新为最后状态历史明细在另一张表中。解决做统计类需求前先查表结构文件里有没有“历史”“备份”“archive”字样的表按时间段汇总两张表再合并。我现在的习惯是先写行数对比脚本两张表都数一遍再决定用哪张。5.2 翻车二把 E8 的表名套到 E9脚本报“对象名无效”现象迁移 E8 的报表脚本到 E9执行第一条查询就报错提示对象名无效。原因E9 调整了资源模型部分 hrm 开头的人员组织表换了命名归属旧脚本找不到新表名。解决先跑SELECT name FROM sys.tables WHERE name LIKE %resource%之类的前缀探测语句把新表名找出来后再改写关联关系。别硬背表名表结构文件就是给你查的。5.3 翻车三流程待办关联表一对多直接 join 导致行数爆炸现象查某个人待办数量结果返回几千行明显超出实际待办。原因同一流程同时有多个节点待办或同一节点多候选人一条流程实例在待办表里对应多行。解决先对 requestid 做 DISTINCT 计数确认合理的行数范围再决定是否要按节点过滤。同事后来总结了一句凡是从流程实例关联到待办表默认一定会多行除非你有业务条件能证明它唯一。5.4 翻车四枚举字段瞎猜把状态当成布尔值现象过滤“有效人员”时写了status 1结果在职人员都被过滤掉大半。原因状态字段不是 0/1 布尔1 可能代表试用、2 代表正式、3 代表离职各版本枚举定义不同。解决在表结构脚本里搜注释或者在文件里找枚举解释。如果找不到用SELECT DISTINCT status, COUNT(*)看分布再结合已知人员推断含义。5.5 翻车五以为主键都是“id”直接按主键连带删除现象按人员 ID 清理测试数据时把关联表的记录也误删了。原因泛微很多表主键字段名不是 id而是“表名首字母 id”或干脆是编号字段靠名称猜测主键极易张冠李戴。解决任何删除/更新操作前用第 3 章的信息架构查询确认主键列。生产环境写批量脚本前我强制要求先做一次 SELECT 验证不确认主键列不动手。6. 拿到表结构后的第一个下午验证、抽样、建字典6.1 验证表清单与脚本一致性解压文件后我建议把核对做成一个固定动作先统计脚本里的建表数量再看目标库里实际表数量不一致就说明脚本没跑全或者库里有额外扩展表。用一句 SQL 就能和脚本对账SELECT COUNT(*) FROM sys.tables;这个数字和脚本里的 CREATE TABLE 数量一致说明结构对得上。数量不一致时优先查一下 E9 自带系统表是否被过滤别急着把差异当问题。6.2 跑三行抽样语句肉眼验证字段含义结构正确不等于你能用好它。我会抽三个典型表各跑一条统计验证字段值与业务含义对得上SELECT status, COUNT(*) FROM hrmresource GROUP BY status; SELECT requestid, COUNT(*) FROM workflow_requestbase GROUP BY createdate ORDER BY createdate DESC; SELECT docversion, COUNT(*) FROM docmain GROUP BY docversion;这三条查询分别验证人员状态枚举、流程表按日期分布、文档版本分布。如果某个表查出来的数据量和公司规模完全对不上说明你可能查错了表回到表结构文件确认。这样做的价值是在你把表名写进正式代码前先把假设验证掉。6.3 把关键表字段导出成自己的数据字典与其每次翻几百条建表语句我更建议把高频率使用的表字段一次性导出成笔记或 CSV维护一份个人表字典。方法很简单把第 3 章的字段查询去掉 WHERE 过滤换成你关心的几张表名执行后导出结果即可。之后做集成、排障、评审时直接翻字典效率高很多。从那以后我每次拿到新的 E9 表结构压缩包都强制自己先走一遍核对流程先查数量再抽三行数据验证字段最后导出字典。磨刀不误砍柴工至少省掉一半的“字段名猜谜”时间。希望这篇笔记能帮到你。本文还有配套的精品资源点击获取
