企业官网建设流程全解析

做泛微OA运维和二次开发的人，迟早都会撞上同一个需求：流程表单里的已归档数据和未归档数据，要一次性查出来。尤其到了月底、季度末，领导一句话“把所有报销单、合同审批、用印申请的归档和未归档的都拉出来统计一下”，你要是只查了主表，那数据铁定缺一块；要是分两张表查完手工拼，又累又容易出错。最稳的办法，就是用SQL联表查询，把归档数据和非归档数据放在同一条查询里处理。

这篇文章我直接讲实操。先说归档机制是怎么回事，再带你把核心表定位出来，最后给出一套可以“抄作业”的联查SQL模板，以及我在实际项目里踩过的坑。无论你是泛微OA的系统管理员、二次开发工程师，还是负责报表取数的数据库人员，这篇都适用。

1. 先把“归档”这件事搞清楚

1.1 泛微流程表单的存储模型

在写SQL之前，得先弄明白泛微OA里流程表单的数据到底存在哪。很多人上来就翻表单设计器，结果发现字段都在界面上，一查数据库就懵了——表单数据根本没放在一张叫“报销单”的表格里。

泛微E-cology的存储逻辑是这样的：流程引擎负责记录流程运转信息，表单引擎负责承载业务字段。流程实例在workflow_requestbase这类流程主表里，而表单上你填写的那些业务字段（比如报销金额、出差事由、供应商名称），会被存到根据表单编码动态创建的物理表里，通常命名类似formtable_main_x。

之所以叫“动态创建”，是因为表单设计器里每增加一个表单或修改一个字段，系统就可能调整表结构或新建表。不同版本、不同实施环境的表名规则会有差异，所以第一步永远不是猜表名，而是先去系统里把表单对应的物理表找出来。

这一步也有个好处——你已经提前知道了核心关联字段：流程主表靠requestid和表单数据表关联。这个字段是泛微流程数据联查的“万金油”，后面所有SQL都离不开它。

1.2 归档的两种常见落地方式

“归档”这个词在不同客户环境里含义差别很大，这也是最容易把人绕晕的地方。根据我接触过的项目，泛微OA里的归档落地方式基本可以归成两类。

第一类是“标记归档”。流程结束后，管理员在系统里做归档操作，实际数据不搬走，只是在流程表或表单表上加了一个归档状态标记。这种情况最简单，查询时只需要多带一个状态条件的判断，不需要跑归档表。

第二类是“物理迁移归档”。数据量大了以后，DBA或运维通过定时任务、存储过程，把满足条件的历史流程数据从formtable_main_x搬到归档表（常见命名formtable_archive_x）或者归档库里。这种情况下，未归档和已归档的数据不在同一张表里，联查时就必须用UNION ALL或者视图把两个数据源合并。

最头疼的是很多客户环境是混合模式：部分表单走了物理归档，部分表单只做标记。所以我在项目里拿到需求后，从来不会直接按某个固定写法套，而是先执行几条探查SQL，确认当前环境到底属于哪种归档方式。下文会专门讲怎么探查。

2. 联表查询前，先定位这几张核心表

2.1 怎么找到表单对应的物理表名

在泛微后台，表单设计器里能看到表单编码，比如差旅报销单编码是form_bx、合同审批是form_ht。但物理表名往往不是直接叫form_bx，而是类似formtable_main_12或formtable_main_81这样的数字表。

我常用的定位方法有两种。第一种是在E-cology的数据库里查表单注册表，泛微一般在formtable或formfield等系统表里记录了业务表单与物理表的映射关系。可以执行类似下面这条SQL：

-- 在泛微系统库里查表单编码对应的物理表名 SELECT id, tablename, tablenote FROM formtable WHERE tablenote LIKE '%差旅%' OR tablename LIKE '%formtable_main%' ORDER BY id;

第二种更直接：到流程表单设计器里看页面上生成的HTML或脚本，往往能翻到tablename=formtable_main_xx的信息。只要拿到表名，后面所有问题都好办了。

需要注意的是，子表（明细表）一般叫formtable_detail_x，字段行列对应关系可以从formfield表里查。比如你要查报销单的多条明细，就需要额外关联子表，而不是在主表里傻等一个字段。

2.2 归档表有哪些命名套路

物理迁移归档的场景，归档表命名在不同实施方手里完全不统一。我见过的命名至少有以下几种：

所以，查询前不能想当然，最稳妥的探查方式是分别统计主表和疑似归档表的记录数、最大时间、最小时间，对比确认归档数据到底落在哪。我一般会顺手查一下：

-- 探查：主表与归档表的数据分布对比 SELECT '主表' AS src, COUNT(*) AS cnt, MIN(createtime) AS min_time, MAX(createtime) AS max_time FROM formtable_main_12 UNION ALL SELECT '归档表', COUNT(*), MIN(createtime), MAX(createtime) FROM formtable_archive_12;

如果归档表记录数远大于主表，或者时间范围能衔接上，基本可以确定是物理迁移归档。如果归档表是空的或者不存在，那就大概率是标记归档，老老实实去主表查状态位就行。

2.3 联表时最常用的关联关系

把表单物理表找到之后，联查需求往往还不只是“主表 + 归档表”。我们通常还需要把创建人姓名、部门名称、流程名称、流程状态这些信息带出来，这就涉及下面几张核心表的关联。

• workflow_requestbase：流程请求主表，核心字段是requestid（流程ID）、workflowid（流程定义ID）、creater（创建人ID）、createtime（创建时间）、requestname（流程标题）。
• workflow_base：流程定义表，用于把workflowid翻译成流程名称。
• hrmresource：人力资源表，用于把创建人ID翻译成姓名。
• hrmdepartment：部门表，用于把部门ID翻译成部门名称。

联查思路等于把“流程实例 + 业务表单 + 人员组织”三块串起来。流程实例提供公共基础信息，业务表单提供业务字段，人员组织用于展示和过滤。逻辑理顺之后，SQL写起来就不容易乱。

3. 归档与未归档联查SQL到底怎么写

3.1 核心思路：先分开查，再合并，最后统一关联

很多人第一次写归档联查，上来就想用FULL JOIN把主表和归档表拼成一个大宽表。这种做法在两张表结构完全一致时倒也能跑，但一旦两张表的字段命名、字段数量略有差异，写出来的SQL又长又难维护。我的习惯是三步走：先分别查出“未归档数据集”和“已归档数据集”，用UNION ALL合并成一份完整数据集，然后再和流程表、人员表、部门表做关联。

为什么用UNION ALL而不是UNION？归档和未归档理论上数据不会重叠，用UNION反而会增加一次去重排序的开销，数据量大时性能特别难看。这里直接用UNION ALL，两个分表查询的结果集直接首尾相接，既保证数据完整，还能让SQL执行计划更简单。

3.2 未归档部分怎么查

假设差旅报销单的物理主表是formtable_main_12，主表里有requestid、costtype（费用类型）、totalamount（报销总金额）、applydate（申请日期）这些字段。未归档数据一般就是指还在主表里、没有被标记为归档的数据。

如果环境采用“字段标记归档”，查询时只要加一个过滤条件：

-- 未归档：主表数据且归档标记为0（或NULL） SELECT r.requestid, r.requestname, r.createtime, e.lastname AS creater_name, m.costtype, m.totalamount, m.applydate FROM formtable_main_12 m INNER JOIN workflow_requestbase r ON m.requestid = r.requestid LEFT JOIN hrmresource e ON r.creater = e.id WHERE (m.isarchive = 0 OR m.isarchive IS NULL);

注意，不同环境里的归档标记字段名并不统一，可能叫isarchive、archiveflag、archivestatus，甚至可能在一个单独的归档记录表里。所以建议先执行SELECT * FROM formtable_main_12 WHERE 1=0，把表结构拉出来看一遍，确认到底有没有这个字段。

3.3 归档部分怎么查

归档部分的查询结构和未归档几乎一致，只是数据来源变成了归档表。如果归档表在主库里，写法就是这样：

-- 已归档：从归档表取数 SELECT r.requestid, r.requestname, r.createtime, e.lastname AS creater_name, a.costtype, a.totalamount, a.applydate FROM formtable_archive_12 a INNER JOIN workflow_requestbase r ON a.requestid = r.requestid LEFT JOIN hrmresource e ON r.creater = e.id;

有些时候，归档操作会把流程主表里的历史流程也一并清理到历史库，那么归档表里的requestid在workflow_requestbase里可能根本查不到。这种情况下，关联流程主表就变成了关联归档流程表，具体表名要看归档方案，一般会有对应的workflow_requestbase_archive或历史库。这里必须灵活判断，不要硬套。

3.4 完整联查SQL模板

把上面两部分合并，再统一把流程名称、部门名称都关联出来，就是一套完整可用的归档与未归档联查模板。

-- ============================================= -- 泛微OA流程表单归档与未归档联表查询模板 -- 适用场景：同库存在归档表，且归档表与主表结构一致 -- 前提：已确认物理表名、归档表名、关联字段 -- ============================================= SELECT datasource.src_type, r.requestid, wb.workflowname, r.requestname, r.createtime, e.lastname AS creater_name, d.departmentname, datasource.costtype, datasource.totalamount, datasource.applydate FROM ( -- 未归档数据集 SELECT '未归档' AS src_type, m.requestid, m.costtype, m.totalamount, m.applydate FROM formtable_main_12 m WHERE (m.isarchive = 0 OR m.isarchive IS NULL) UNION ALL -- 已归档数据集 SELECT '已归档', a.requestid, a.costtype, a.totalamount, a.applydate FROM formtable_archive_12 a ) datasource INNER JOIN workflow_requestbase r ON datasource.requestid = r.requestid INNER JOIN workflow_base wb ON r.workflowid = wb.id LEFT JOIN hrmresource e ON r.creater = e.id LEFT JOIN hrmdepartment d ON e.departmentid = d.id WHERE DATEPART(YEAR, r.createtime) = 2025 ORDER BY r.createtime DESC;

这套模板的核心价值在于：业务字段区域只出现在内层合并中，外层统一处理公共字段的关联和过滤，以后加条件、加字段都很方便。

几点说明：

• 第一列src_type用来标识数据来自归档还是未归档，便于定位和核对。
• 外层WHERE过滤条件尽量用在流程主表的字段上（比如创建时间、流程ID），不要在内层两张分表里各写一遍，避免条件重复、逻辑分散。
• 在实际项目里，建议把这段SQL封装成视图或者存储过程。报表工具只负责SELECT * FROM v_xxx，运维改逻辑时只改视图，不用动报表。

4. 真实场景实战：差旅报销单归档未归档统计

4.1 需求背景

我这里讲一个实际做过的需求：公司行政部要求统计2025年1月到现在所有差旅报销单的数据，包括已经归档和未归档的，需要展示流程标题、报销人、部门、费用类型、报销金额、申请日期，并且要标出每一条数据是归档还是未归档。

这个需求的关键点有两个：第一，不能漏数据；第二，要能快速区分归档状态。拿到需求后，我按前一节的思路，先探查表结构，确认主表是formtable_main_12，归档表是formtable_archive_12，两个表字段一致。然后直接套用模板。

4.2 执行结果长什么样

查询结果大概是这样一组数据（示意）：

通过src_type字段，行政部的人一眼就能看出每一单的归档状态。统计金额时直接在外层套GROUP BY：

SELECT datasource.src_type, ISNULL(SUM(datasource.totalamount), 0) AS total_amount, COUNT(*) AS record_count FROM ( SELECT '未归档' AS src_type, m.requestid, m.totalamount FROM formtable_main_12 m WHERE (m.isarchive = 0 OR m.isarchive IS NULL) UNION ALL SELECT '已归档', a.requestid, a.totalamount FROM formtable_archive_12 a ) datasource INNER JOIN workflow_requestbase r ON datasource.requestid = r.requestid WHERE r.createtime >= '2025-01-01' GROUP BY datasource.src_type;

4.3 数据校验不能省

这种脚本上线前，我强烈建议做一次数据完整性校验。操作很简单：把主表的记录数、归档表的记录数、联查结果的记录数分别统计出来，三者做横向对比。

-- 对比总行数 SELECT (SELECT COUNT(*) FROM formtable_main_12 WHERE (isarchive = 0 OR isarchive IS NULL)) AS unarchived_cnt, (SELECT COUNT(*) FROM formtable_archive_12) AS archived_cnt, (SELECT COUNT(*) FROM ( SELECT m.requestid FROM formtable_main_12 m WHERE (m.isarchive = 0 OR m.isarchive IS NULL) UNION ALL SELECT a.requestid FROM formtable_archive_12 a ) t) AS merged_cnt;

如果unarchived_cnt + archived_cnt = merged_cnt，说明合并没丢数据、没重复数据。这一步虽然看起来笨，但能挡掉很多后患。我遇到过不止一次因为归档任务中途报错导致部分数据两边都有、或者两边都没有的情况，这类脏数据不是写SQL能解决的，但靠这个核对SQL能第一时间发现并找运维处理。

5. 常见问题与排查技巧实录

5.1 两边都查不到数据，或者两边都重复了

这是归档联查里最坑的问题。部门运维图省事，直接手工执行归档存储过程，结果归档过程没有做“迁移后删除主表记录”的步骤，导致主表和归档表里都保留了同一份数据。反过来，如果归档前没有完整复制数据，则可能出现两边都缺。

处理办法：先把重复数据找出来，比如用requestid分组统计：

SELECT requestid, COUNT(*) AS cnt FROM ( SELECT m.requestid FROM formtable_main_12 m WHERE (m.isarchive = 0 OR m.isarchive IS NULL) UNION ALL SELECT a.requestid FROM formtable_archive_12 a ) t GROUP BY requestid HAVING COUNT(*) > 1;

如果查出了重复项，再去原系统里确认数据版本，确定保留哪一份，然后修正。记住，修复前一定先备份原表数据。我在生产环境吃过这个亏，再也不敢不备份就直接删除。

5.2 UNION ALL两边字段类型不一致，直接报错

用UNION ALL时，SQL Server要求上下两个结果集的列数相同、对应列的数据类型兼容。但归档表经过某些迁移工具处理后，字段类型可能会变化。比如主表里totalamount是decimal(18,2)，归档表里被改成了varchar(50)，合并时直接报转换错误。

排查方法不难：分别查看两张表的字段类型，用sys.columns查一下：

SELECT t.name AS table_name, c.name AS column_name, ty.name AS data_type FROM sys.tables t INNER JOIN sys.columns c ON t.object_id = c.object_id INNER JOIN sys.types ty ON c.user_type_id = ty.user_type_id WHERE t.name IN ('formtable_main_12', 'formtable_archive_12') ORDER BY t.name, c.column_id;

类型不一致的情况下，优先在子查询里用CAST或CONVERT统一成同一类型。能不改表结构就不改表结构，生产环境里动表结构风险太大了。

5.3 数据量大之后，联查慢得让人抓狂

归档表累积了很多年历史数据，动辄几百万行，联查的时候如果直接全表扫，一条统计报表能跑十分钟。我常用的优化手段有这么几个。

第一，内层子查询尽早过滤。比如统计2025年数据，就先把主表和归档表里的2025年数据筛出来再合并，而不是先把全量数据合并再在外层过滤。当然，过滤条件必须能走到索引上，如果主表和归档表的createtime上有索引，这个优化效果立竿见影。

第二，给requestid建索引。这一步主要是检查现有的复合索引是否覆盖关联字段。很多泛微环境的表单表是按requestid做聚集索引的，如果没有，需要和DBA确认能否补一个NONCLUSTERED INDEX。

第三，把结果落成临时表。如果同一份数据要被报表工具反复查询，不要把临时结果反复算。可以先SELECT ... INTO #temp_merged，再基于临时表做分组和汇总。临时表上再按常用过滤字段建索引，查询速度能快一个数量级。

5.4 日期字段为空或者格式不统一

泛微环境里日期字段有时候会存成字符串，尤其是通过集成接口写入的数据，格式可能是2025-01-01，也可能是2025/01/01，还有可能直接是空字符串。用DATEPART(YEAR, r.createtime)过滤时，遇到空值不会报错，但统计结果可能莫名其妙少数据。

我的习惯是，先检查日期字段的空值率：

SELECT COUNT(*) AS total_cnt, SUM(CASE WHEN createtime IS NULL OR createtime = '' THEN 1 ELSE 0 END) AS empty_cnt FROM formtable_main_12;

如果空值比例较高，需要先和业务部门确认这些数据怎么统计，再决定是过滤掉还是单独归到“日期未知”的分组里。千万不要默认日期一定正确，数据质量问题往往藏在你不看的角落。

写到最后的一些心得

做了几年泛微OA的数据运维，我最大的感受是：归档联查这类需求，难点不在于SQL语法，而在于“数据落在哪儿、怎么标记的、有没有脏数据”。不同实施项目、不同版本、不同归档方案，表结构和行为都不完全一样。所以我的建议是，拿到需求先花10分钟探查表结构、统计行数、确认归档机制，再花10分钟写SQL，剩下的时间都用来做数据校验。别一上来就套模板，套模板一时快，数据错了返工更麻烦。

最后再分享一个小技巧：如果这种“归档+未归档”的组合查询以后会经常用到，不要每次都写一大段UNION ALL。可以在库里建一个视图，把合并逻辑封装起来，比如v_form_bx_all，以后所有报表都从视图取数。归档表结构变了，只需要改视图定义，报表端一行都不用动。这个习惯，长期看能给运维省下大量时间。