泛微OA E9表结构Zip实战：从建库到查询避坑指南-平芜编程栈

简介：泛微E9表结构压缩包是面向泛微OA协同办公平台二次开发的数据库结构参考材料，适合需要做系统集成、权限优化或数据迁移的开发者与运维人员。压缩包整体约3.67MB，虽然资源页未标注具体文件数与类型，但根据内容介绍，可确定其中包含E9系统各核心业务模块的表结构说明，或以SQL脚本、数据库设计文档形式呈现，涉及用户信息、流程定义、任务实例、文档管理、权限角色、组织结构、日程管理、通讯录等常用表。已有289人学习下载。借助字段定义、数据类型、主外键关系，可以完整还原系统数据模型，支撑管理员合理制定权限策略、调整审批流，也能帮助开发者对接ERP、HR等外部系统，并提升数据迁移和性能调优效率。对于需要深入理解和扩展泛微OA能力的技术团队，这份资料具有很高的参考价值。

1. 泛微OA E9表结构.zip：先弄清楚里面装了什么再动手

泛微OA E9表结构.zip 是不少实施、二开和运维同事收到后容易“光速翻车”的文件包。解压之后，你大概率看到一堆 .sql 脚本，或者几个按数据库类型区分的目录，部分包里还附带 HTML/Excel 版本的数据字典说明文档。这些内容描述的是 E9 产品运行所需的全部数据库表结构：流程引擎相关表、组织人事表、系统配置表、表单数据物理表。它的作用有且只有两个：一是在全新数据库里把 E9 的表建出来，二是给二次开发和报表开发当“数据地图”，让你知道某条流程数据到底落在哪张表、哪个字段上。做实施布库、接口对接、数据迁移、BI 取数的人都绕不开它。这篇笔记只讲一件事：拿到这份表结构包之后，怎么把它用得明明白白，少走弯路。

这里有个反直觉的坑：这份 zip 往往不是一份“总表”，而是多个数据库版本脚本的集合，直接全量执行大概率报错，或者执行成功却不知道该查哪张表。后面章节会按“确认版本 → 导入建库 → 读懂核心表 → 写实战 SQL → 避坑 → 沉淀字典”的顺序展开，适合已经有 E9 环境、或者刚收到这份 zip 的从业者照着复现。

2. E9表结构包落地：选对数据库版本，把建表脚本变成能查的库

2.1 先确认E9版本和数据库类型：这份zip最容易被误用的地方

泛微 E9 本身可以在多种数据库上跑，实际项目里最常见的是 SQL Server、Oracle 和 MySQL 三类，部分政企项目还会用国产数据库适配版本。表结构包通常也会按数据库类型拆成不同脚本，但命名规则并不统一，有的叫“SQLServer目录”“Oracle目录”，有的只是在文件名后缀上区分，还有的干脆全部平铺在一个文件夹里。你不先确认数据库类型就直接执行脚本，第一个报错往往就是语法不兼容。

我的习惯是解压后先别急着导入，花三分钟做两件事。

第一，看有没有 readme、说明.txt 或者按库拆分的子目录。E9 实际部署时不只是“一个库”，主库、日志库、第三方集成库有时候是分开的，表结构包如果按库拆分，文件命名里一般能看出来，例如带 log、integration、ecology 等字样。别把日志库的脚本执行到主库里。

第二，如果命名不清晰，随机打开一个 .sql 文件看语法特征。SQL Server 脚本里会出现[dbo].[ec_workflow_requestbase]这种方括号写法；Oracle 脚本里会大量出现TABLESPACE、COMMENT ON COLUMN；MySQL 脚本则使用反引号`包裹表名和字段名。只看文件头几行就能判断出来。

确认好之后，再决定到底用哪一个脚本。常见做法是优先选择和目标库完全匹配的版本，而不是“先跑起来再说”。某公司当初把 SQL Server 版本的脚本执行到 MySQL 库里，光修字段类型就花了两天，后面报表还是对不上。

2.2 以SQL Server为例执行建表脚本：最小操作步骤

以最常见的 SQL Server 环境为例，整个导入过程并不复杂，但有几个顺序上的讲究。假设你已经把 zip 解压到D:\E9_Scripts，里面是一个完整的建表脚本，或者多个按序号排列的脚本文件。

第一步，在 SQL Server 里新建一个数据库，命名建议直接叫ecology或者按项目规范来，排序规则选择Chinese_PRC_CI_AS，避免日后查中文出现乱码排序问题。

第二步，在 SSMS 中打开主脚本文件执行。如果脚本是按序号拆分的，按顺序逐个执行，不能跳跃。脚本执行时间取决于机器性能，几百张表通常几分钟内能跑完。

第三步，如果你更习惯命令行，用 sqlcmd 也可以，命令示例如下：

sqlcmd -S . -d ecology -E -i "D:\E9_Scripts\01_create_tables.sql" -b

-S .表示连接本机默认实例，-d ecology指定目标数据库，-E使用 Windows 身份认证，-i指定要执行的脚本文件，-b的作用是遇到错误就终止执行并返回非零退出码。这个-b参数很重要：默认情况下 sqlcmd 碰到报错会继续往下跑，最后你根本不知道哪些表建成功了，哪些失败了。加-b后脚本在第一条错误处停下来，便于定位问题。

执行完成后不要直接开始写业务查询，先做一轮自查，见下一节。

2.3 导入完成后先自查三件事：表数量、主键、说明注释

脚本执行完不代表一切正常，我一般会在库里跑三条 SQL，把“建表是否完整”这件事量化确认一下。

第一条查表数量，看核心前缀表是否齐全：

SELECT COUNT(*) AS ec表数量 FROM sys.tables WHERE name LIKE 'ec\_%' ESCAPE '\'; SELECT COUNT(*) AS hrm表数量 FROM sys.tables WHERE name LIKE 'hrm%';

ESCAPE '\'是为了让\_被当成普通下划线而不是通配符，否则ec_会被理解成“ec 开头、任意字符、任意长度”，统计结果会偏大。如果你期望看到的数量和实际数量差距很大，说明脚本没跑全，先回到执行环节排查。

第二条验证最关键的表是否存在。

SELECT OBJECT_ID('ec_workflow_requestbase') AS 流程主表对象ID, OBJECT_ID('hrmresource') AS 人员表对象ID;

返回NULL说明表没有建成功，返回数字说明对象存在。这一步是给后续章节的实战查询打底。

第三条检查字段说明注释是否存在。

SELECT TOP 10 t.name AS 表名, c.name AS 字段名, ep.value AS 注释 FROM sys.tables t JOIN sys.columns c ON t.object_id = c.object_id LEFT JOIN sys.extended_properties ep ON ep.major_id = c.object_id AND ep.minor_id = c.column_id AND ep.name = 'MS_Description' WHERE t.name = 'ec_workflow_requestbase';

如果注释列大面积是 NULL，说明这份表结构 zip 是“纯建表脚本”，字段说明可能在配套的 HTML/Excel 数据字典文档里，需要另外打开文档看。这不是导入失败，只是信息来源不同，别慌。

3. 读懂E9表结构主干：流程数据是怎么从发起查到明细的

3.1 流程实例主表：ec_workflow_requestbase 先背熟

进入 E9 表结构之后，最先要建立的概念是“一条流程在数据库里长什么样”。你发起一个合同审批，数据库里并不是只在一个表里插一条记录，而是至少要在流程主表里写一条“流程实例”记录，再往表单对应的物理表里写业务数据。这个“流程实例”记录就存在ec_workflow_requestbase里。

这张表里最常见的字段有requestid（流程实例 ID，主键）、requestname（流程标题，就是你发起时填的主题）、workflowid（关联流程定义表workflow_base，用来知道你走的是哪个流程）、creater（发起人 ID，关联hrmresource）、createdate（发起时间，注意是字符串还是日期时间类型，E9 里常见是字符串格式）、status（流程状态，但不同版本取值含义有差异，后面避坑章节会细说）。

你可以先跑一条最简单的 SQL 感受一下这张表的内容：

SELECT TOP 20 requestid, requestname, workflowid, creater, createdate, status FROM ec_workflow_requestbase ORDER BY requestid DESC;

刚执行完建表脚本的库是空的，这条 SQL 会返回 0 行，这是正常的。它的意义是让你熟悉字段名和字段顺序，等到联调环境有真实数据后再跑，你就能立刻把“流程标题”“发起人”“发起日期”和业务数据对应起来。

理解这张表之后，后续所有“查流程数据”的需求都会以它为起点，再通过workflowid拿到流程名、通过creater拿到发起人信息。这张表是整个 E9 表结构里你花时间最值得的一张表。

3.2 组织与人员：hrmresource 及周边表为什么永远是核心

如果说ec_workflow_requestbase是流程数据的主干，那么hrmresource就是所有“人”信息的唯一权威来源。E9 里几乎所有跟人相关的字段，最终都通过一个数字 ID 关联到这张表上。

hrmresource的关键字段包括id（人员 ID，其他表里的人字段都是拿这个 ID 做关联）、loginid（登录账号，也就是你登录 OA 时输的那个）、lastname（姓名，泛微历史版本一直用这个字段名，而不是username）、departmentid（部门 ID，关联hrmdepartment）、subcompanyid1（分部/公司 ID，多分部架构下用来区分人员属于哪个公司）。

配套的两张表也建议一起记住：hrmdepartment存部门信息，核心字段是id和departmentname，通过supdepartmentid可以上下级递归；hrm_subcompany存公司/分部信息，核心字段是id和subcompanyname。

实际看表结构时你会发现，人员表和部门表在设计上并不复杂，但有个细节会让很多人踩坑：离职人员不会从hrmresource里物理删除，而是通过状态字段或离职时间字段标记。所以写统计类 SQL 时，一定要根据项目实际确认“有效人员”的过滤条件，不能默认表里所有人都是在职状态。

验证这张表的数据也很简单：

SELECT TOP 5 id, loginid, lastname, departmentid, subcompanyid1 FROM hrmresource;

有数据的环境下，你会看到loginid里有类似zhangsan、wangwu这样的账号，但有些项目会带域前缀或工号后缀，写查询时要注意匹配方式，后面实战章节会专门提到。

3.3 自定义建模表uf_前缀：标准包查不到的动态表

标准表结构 zip 里能覆盖流程引擎、组织架构、系统配置，但覆盖不了一个东西：客户在实施过程中用 E9 建模引擎自建的业务表。这些表才是真正存放“合同台账”“项目信息”“报销明细”的地方。

E9 的建模引擎在创建业务对象时，会在数据库里生成对应的物理表。很多项目里这些表名以uf_开头，后面跟业务对象的标识，例如uf_contract_main、uf_contract_detail；也有实施团队自定义前缀的，比如bill_、biz_。前缀本身不是固定的，这和项目初始化时的建模配置有关。

你如果翻遍表结构 zip 没找到uf_开头的表，是正常的，因为这份 zip 是标准产品表结构，不包括客户现场后建的建模物理表。那么实际项目中怎么发现这些表？直接在库里搜：

SELECT name AS 表名, create_date AS 创建时间 FROM sys.tables WHERE name LIKE 'uf\_%' ESCAPE '\' OR name LIKE 'bill\_%' ESCAPE '\' ORDER BY create_date;

找到之后重点关注两件事。第一，表里有没有requestid或docid这类字段。建模表和流程关联时，系统通常会写入这些字段作为与ec_workflow_requestbase的关联键，有它们才能把流程实例和业务数据串起来。第二，主表和明细表的关系。主表一条记录对应流程一张主表单，明细表通过主表 ID 关联多条明细记录。

这部分没有统一答案，每张建模表都不一样，只能靠“先看表结构、再对数据”的方式摸。好在表名本身通常有业务含义，配合字段名的中文注释，十分钟内能大致判断出来。

4. 用E9表结构写实战SQL：从库表到业务数据的两种典型查询

4.1 查询某人员发起的流程及当前状态

现在把前面的表串起来。最常见的需求是：给我查某个用户发起了哪些流程，现在走到哪个节点，流程叫什么名字，什么时候发起的。

这是一个三表关联查询：ec_workflow_requestbase关联hrmresource拿发起人姓名，再关联workflow_base拿流程名称。

SELECT wr.requestid AS 流程实例ID, wr.requestname AS 流程标题, wb.workflowname AS 流程名称, hr.lastname AS 发起人, wr.createdate AS 发起时间, wr.status AS 流程状态 FROM ec_workflow_requestbase wr JOIN hrmresource hr ON wr.creater = hr.id JOIN workflow_base wb ON wr.workflowid = wb.workflowid WHERE hr.loginid = 'zhangsan' ORDER BY wr.createdate DESC;

JOIN hrmresource hr ON wr.creater = hr.id是人员关联的标准写法，creater存的是hrmresource.id，不是loginid，这一步别搞反。workflow_base是流程定义表，workflowname就是在 OA 后台“流程引擎”里配置的流程名称。

有个实际查询里的细节：loginid的匹配不一定总能用等号。有些项目做域集成后，人员登录名会变成DOMAIN\zhangsan这类带前缀的格式，有的还区分大小写。我一般会先用LIKE探一下数据长什么样：

SELECT TOP 20 loginid, lastname FROM hrmresource WHERE loginid LIKE '%zhangsan%';

如果返回多条记录，再决定用等号还是模糊匹配。这个探路动作能省不少排查时间。

4.2 主表关联建模物理表：带明细的关键代码

第二条典型需求是查流程里的业务数据，比如“合同审批通过后，合同编号和合同金额在哪张表里”。这类查询要从ec_workflow_requestbase关联到建模物理表，但建模物理表不是标准表，关联字段要现场确认。

假设你已经通过第 3.3 节的方式找到了合同主表uf_contract_main，并且确认它里面有requestid字段，那么查询可以这样写：

SELECT wr.requestname AS 流程标题, hr.lastname AS 申请人, uf.contract_no AS 合同编号, uf.amount AS 合同金额, uf.sign_date AS 签订日期 FROM ec_workflow_requestbase wr JOIN hrmresource hr ON wr.creater = hr.id LEFT JOIN uf_contract_main uf ON uf.requestid = wr.requestid WHERE wr.workflowid = 123 AND uf.amount > 100000 ORDER BY wr.createdate DESC;

这里我用的是LEFT JOIN而不是INNER JOIN，原因是建模物理表里的requestid不一定每条都回填成功，尤其在流程尚未结束或者表单被退回重填的情况下，INNER JOIN会把数据悄悄丢掉，而LEFT JOIN至少能让你发现哪些流程没有关联上业务数据。

WHERE wr.workflowid = 123这个条件，需要你先在 OA 后台或者workflow_base表里确认流程对应的workflowid。不同环境的流程 ID 不一样，别把这个值写死到文档里当通用答案。

如果业务表还有明细，比如一张合同对应多笔付款计划，明细表通常是uf_contract_payplan，里面会有主表 ID 字段，再用主表 ID 关联明细表即可。流程模式下明细表里一般还会带requestid或主表外键，具体用哪一个，同样以现场表结构为准。

4.3 E9常用表速查：一张表记住核心入口

为了让你在拿到其他表结构包时不至于迷失，这里按业务域整理一份常用表速查。这不是完整清单，但覆盖了八成以上日常查询会用到的入口。

表名	业务含义	核心字段
ec_workflow_requestbase	流程实例主表	requestid, requestname, workflowid, creater, createdate
workflow_base	流程定义表	workflowid, workflowname
workflow_nodebase	流程节点定义表	nodeid, workflowid, nodename
hrmresource	人员表	id, loginid, lastname, departmentid, subcompanyid1
hrmdepartment	部门表	id, departmentname, supdepartmentid
hrm_subcompany	分部/公司表	id, subcompanyname
ec_workflow_requestdoc	流程文档记录表	requestid, docid, workflowid
uf_% / bill_% 表	建模引擎生成的业务物理表	含 requestid 或主表外键 + 业务字段

ec_workflow_requestdoc这张表要特别提一下，它保存的是流程和表单文档的关联记录，不代表所有业务字段都存里面。表单的业务字段大概率存在建模物理表里，所以查业务数据时优先找建模表，而不是在 requestdoc 里翻字段。这正好引出下一章的避坑内容。

5. E9表结构展开后的常见问题与避坑：每一条都是真踩过的

5.1 现象：全量执行脚本报“对象已存在”

拿到 zip 之后最容易犯的错就是把所有脚本一股脑执行。报错通常是这样：执行到某个CREATE VIEW或CREATE INDEX时提示“数据库中已存在名为 xxx 的对象”。原因主要有两个：一是脚本里有重复定义，同一个视图或索引在多个文件里出现；二是把两套数据库版本的脚本混在同一个库里执行了，SQL Server 脚本执行完又跑去执行 Oracle 脚本，低版本对象和高版本对象互相冲突。

解决方法是执行前先做版本隔离，确认当前库里只跑一套目标数据库的脚本。用 sqlcmd 加-b参数执行，遇到第一个错误就停下来，先查sys.objects看冲突对象属于哪个脚本，再决定跳过还是重建。不要用“出错继续”的模式跑完整套脚本，最后你得到的库到底缺了多少张表，你根本不知道。

5.2 现象：查流程表单发现字段值对不上

你按标准表的思路去查某个流程的表单数据，结果发现ec_workflow_requestdoc里只有requestid、docid这些关联字段，真正想要的“报销金额”“出差城市”一个都找不到。这是对 E9 存储机制理解偏差导致的典型困惑。

原因在于 E9 的表单数据存储分好几种：流程自带的系统表单、HTML 自定义表单、建模引擎生成的业务表，它们的字段落库位置不一样。很多自定义表单的业务字段直接落在建模物理表里，ec_workflow_requestdoc只是文档关联记录。解决方法是先确认这张流程表单对应的物理表，再去物理表里查字段，而不是在 requestdoc 里大海捞针。定位方法前面章节已经说过：按uf_、bill_前缀搜表，或者看表名和表单标识的对应关系。

5.3 现象：需要的表在zip里根本不存在

翻遍了整个表结构包，也没找到客户提到的“项目台账表”“合同付款计划表”。这不代表表结构包不完整，而是标准产品表结构包本来就不包含实施阶段建模生成的业务表。

真实项目里，客户的自定义业务对象都是在 E9 后台通过建模引擎创建的，创建时系统在数据库里生成物理表，这些表只存在于客户的实际业务库中，不会进到产品自带的表结构 zip 里。解决方法是直接连上目标库，用查询系统表的方式把现有业务表导出来，例如前面写过的WHERE name LIKE 'uf\_%' ESCAPE '\'，再按实际表结构梳理。如果你需要一份“完整表结构”给第三方做接口，应该从目标库反向导出，而不是依赖产品自带 zip。

5.4 现象：表注释为空，数据字典“像是没导入”

跑完建表脚本后，用系统表查字段注释，发现全是 NULL。这不一定是导入失败，而是这份 zip 里的脚本本身没有提取注释。SQL Server 的字段说明存放在扩展属性MS_Description里，如果生成脚本时没有把扩展属性一起导出，你就算重新执行一百遍也不会有注释。

解决方法是分两步走。先找 zip 里有没有配套的 HTML 或 Excel 数据字典文档，泛微实施资料里常见这种文档格式，字段说明以文档形式存在。如果文档也没有，就自己动手生成一份字典，方法见下一章。这个坑的实质是“注释在脚本里还是脚本外”的信息差，别跟导入是否成功混为一谈。

5.5 现象：流程状态字段 status 的含义和你猜的不一样

写流程查询时，很多人会直接按网上流传的“0 表示审批中，1 表示已完成”来写过滤条件，结果数据对不上。ec_workflow_requestbase.status的取值在不同 E9 版本、不同项目配置里是有差异的，有的项目里 0 表示已提交，有的项目里 0 反而是已删除。原因在于 E9 的流程状态本身是枚举值，不同版本演进中做过调整，而 zip 里的注释脚本如果没更新，这个字段的说明就是过时的。

解决办法很简单：先看库里真实数据的分布，再定过滤条件。

SELECT status, COUNT(*) AS 数量 FROM ec_workflow_requestbase GROUP BY status;

把每类状态的数据量列出来，再结合 OA 界面上看到的具体流程状态去对照，反推每档数字的含义。不要猜，不要套网上答案，以现场数据为准。

6. 把E9表结构包变成团队数据字典：两级沉淀

6.1 用系统视图批量导出字段说明

表结构 zip 的价值不该止于“建一次库”。我更推荐的做法是拿到脚本后，顺手跑一段导出的 SQL，把表名、字段名、类型、注释批量导成一张可检索的表或者 Excel 文件，作为团队的数据字典底稿。下面这是 SQL Server 版本：

SELECT t.name AS 表名, c.name AS 字段名, tp.name AS 数据类型, c.max_length AS 长度, CAST(ep.value AS NVARCHAR(500)) AS 字段说明 FROM sys.tables t JOIN sys.columns c ON t.object_id = c.object_id JOIN sys.types tp ON c.user_type_id = tp.user_type_id LEFT JOIN sys.extended_properties ep ON ep.major_id = c.object_id AND ep.minor_id = c.column_id AND ep.name = 'MS_Description' WHERE t.name LIKE 'ec\_%' ESCAPE '\' OR t.name LIKE 'hrm%' OR t.name LIKE 'workflow%' ORDER BY t.name, c.column_id;

max_length对nvarchar类型返回的是字节数，实际字符容量要除以 2，这一点看结果时注意换算。ep.value为 NULL 的字段说明脚本里没有注释，需要人工补充。跑完后把结果复制到 Excel，按表名分组，慢慢补业务含义，这份文件就是项目里的活字典。

6.2 维护一张“表名-业务含义”速查笔记

导出字典之后，再维护一张轻量的速查表，只记录核心表名和业务含义，不用涉及字段级细节，方便新同事快速上手。比如：

表名	业务含义	备注
ec_workflow_requestbase	流程实例主表	一切流程查询的起点
hrmresource	人员表	离职人员不物理删除
uf_contract_main	合同主表（示例）	建模生成，requestid 关联流程
workflow_base	流程定义表	拿流程名称靠它