简介致远OA V8.1 数据字典是一份专为致远OA开发、实施与维护人员整理的数据库结构参考文档重点解决表结构不清晰、二次开发取数困难等问题。资源包为1个PDF文件整体约2.2MB轻量易存适合项目开发、系统移交或日常运维时快速查阅。文档以数据字典形式呈现了ADDRESSBOOK通讯录主表、ADDRESSBOOK_MEMBER外部联系人表等核心表的字段定义逐项列明字段名、数据类型、是否必填与主键标识除ID、创建日期、修改日期等基础字段外还系统梳理了文本型、数字型、日期型三类通用扩展字段以及枚举、选人、选部门、选岗位等业务扩展字段的命名与存储含义。借助这些信息使用者无需逆向反推数据库即可了解人员、组织、通讯录等关键模块的存储逻辑对OA二次开发、报表统计、数据迁移与异常排查均有直接参考价值。目前已有2603人学习下载适合需要深入理解致远OA V8.1库表结构的技术人员参考。1. 致远OA V8.1数据字典没有它流程统计第一晚就要翻车致远OA V8.1 的数据字典在我眼里就是一张“数据库表结构的查找表”。有一回做跨部门流程统计我从 org_member 查到 form_form_inst又去 flow_basic 找流程定义绕了一圈才发现自定义表单的值根本没出现在主表里而是散落在 form_data_ 开头的动态表中。没有数据字典等于在给一个黑匣子做分析每条 SQL 都得先试错一把。数据字典能解决三个问题告诉你表在哪、字段叫什么、业务含义是什么。它适合三类人要给致远 V8.1 做接口和自定义模块的开发、要出报表的分析人员、以及接手别人部署环境的运维。下面直接说获取路径、核心表和踩坑点。2. V8.1数据字典从哪拿官方文档打底、信息模式取真、DBA经验补全2.1 为什么我更信任数据库元数据而不是实施文档V8.1 实施交付时通常会附带一份数据库结构说明各项目叫法不统一。但这几类文档有两个天然缺陷版本滞后以及不含客户自定义建的字段。同一个 V8.1新部署的库和用了五年的老库表数量经常会差出几百张因为表单模块会自动生成大量 form_data_ 开头的动态表。实施文档是设计期的快照数据库才是活的真相。我拿到一套 V8.1 环境第一件事是直接连业务库从 information_schema 或者 Oracle 的 user_tab_columns 里把结构取出来再用实施文档去补业务注释。两边的信息对不上时以实际数据库为准。这一步能省掉后面很多“明明照着文档写却查不到数”的返工。新建搭建的 V8.1 和传承多年的老项目都应该走这个流程而不是去找一份旧 PDF。2.2 V8.1常见表前缀org、flow、form、ctp各管哪一段业务V8.1 建表有一个明显规律按模块分前缀。这个规律能让你拿到一份表名列表时快速分类不用一个个点开看注释。表前缀所属模块代表性表名org_组织、部门、人员、岗位org_organization、org_department、org_memberflow_流程引擎、流程定义、流程实例flow_basic、flow_instance、flow_form_relationform_表单定义、表单实例form_form_def、form_form_instctp_平台公共能力、附件、日志ctp_attachment、ctp_logseeyon_老版本遗留模块和扩展seeyon_affiche、seeyon_meeting这套前缀不是百分之百绝对不同数据库迁移方案里可能保留 seeyon_ 前缀也可能把新表统一收敛到 ctp_ 下。我一般先跑一遍全表列表按前缀分组再对覆盖率低的模块做重点核对。建议你在建字典时也把“表前缀”作为独立一列之后所有按模块筛表的操作都会快很多。2.3 字典该包含哪些列七个字段才算完整只导出表名和字段名是远远不够的。我用的数据字典包含七个字段表名、表注释、字段名、数据类型、字段长度、是否可空、字段注释。主键信息单独再导一份。列来源示例MySQL用途表名information_schema.tables.TABLE_NAME定位模块表注释information_schema.tables.TABLE_COMMENT业务含义字段名information_schema.columns.COLUMN_NAME联表和取数数据类型information_schema.columns.DATA_TYPE判断是否需要转换字段长度columns.CHARACTER_MAXIMUM_LENGTH拼接字符串、建表参考是否可空columns.IS_NULLABLE判断用 LEFT JOIN 还是 INNER JOIN字段注释columns.COLUMN_COMMENT字段业务含义表注释在这套字典里必须保留。V8.1 很多模块表名是缩写org_department 你大概能猜到但 form_deny_reject_info 这种表光看名字猜不出是退文/驳回事宜得看表注释。如果你只想快速跑通可以先精简成“表名、字段名、注释”三列但建议一开始就保留齐全后续写联查 SQL、生成实体映射、做版本 diff 都依赖这些列。3. 把V8.1数据字典导出来MySQL、SQL Server、Oracle三种生产写法数据字典不是凭空来的得从 V8.1 所在的业务库里导。常见部署数据库有三种MySQL、SQL Server、Oracle。以下脚本都可以直接跑按注释修改地址和库名即可。3.1 MySQL 8.xinformation_schema一把梭顺手把注释带出来MySQL 环境下数据字典的核心来源是 information_schema 里的 TABLES 和 COLUMNS 两张视图。用表名关联一次性把表和字段的注释都取出来。SELECT t.TABLE_NAME, t.TABLE_COMMENT, c.COLUMN_NAME, c.DATA_TYPE, c.CHARACTER_MAXIMUM_LENGTH AS LEN, c.IS_NULLABLE, c.COLUMN_COMMENT FROM information_schema.TABLES t JOIN information_schema.COLUMNS c ON t.TABLE_NAME c.TABLE_NAME WHERE t.TABLE_SCHEMA seeyon_v81 AND t.TABLE_TYPE BASE TABLE ORDER BY t.TABLE_NAME, c.ORDINAL_POSITION;这里 TABLE_SCHEMA 要替换成 V8.1 的实际库名示例写成 seeyon_v81。ORDINAL_POSITION 用于保证字段顺序和建表顺序一致方便按表单粒度查看字段。CHARACTER_MAXIMUM_LENGTH 为 NULL 时代表该字段是枚举、文本大字段或者 blob需要再看 DATA_TYPE 判断。导出结果建议用 DataGrip 或 Navicat 的“导出为 Excel”功能落盘后续可以随时筛选。3.2 SQL Serversys.objects联合sys.columns别忘了schemaSQL Server 环境里表注释和字段注释放在扩展属性中约定的名称叫 MS_Description。查询时要特别注意 schemaV8.1 默认可能放在 dbo 下但也有实施方建了独立 schema。SELECT s.name AS schema_name, t.name AS table_name, CAST(ep.value AS NVARCHAR(255)) AS table_comment, c.name AS column_name, typ.name AS data_type, c.max_length, c.is_nullable FROM sys.tables t JOIN sys.schemas s ON t.schema_id s.schema_id JOIN sys.columns c ON t.object_id c.object_id JOIN sys.types typ ON c.user_type_id typ.user_type_id LEFT JOIN sys.extended_properties ep ON ep.major_id t.object_id AND ep.minor_id 0 AND ep.name MS_Description WHERE s.name dbo ORDER BY t.name, c.column_id;这个 SQL 取的是表注释。如果要取字段注释需要把 LEFT JOIN extended_properties 里 minor_id 改成 c.column_id同时增加 ep.major_id c.object_id 的条件。实际的 V8.1 SQL Server 库中很多表上根本没有扩展属性所以 table_comment 为 NULL 很常见不影响字典主体使用但要留意后续补注释的工作量。3.3 Oracleuser_tab_columns配user_col_comments权限边界要看清楚Oracle 上取字典最常用的是 user_tab_comments、user_tab_columns、user_col_comments。user_ 开头的视图只返回当前账号有权限的对象对业务字典来说这是优点也是限制你只能看到项目账号能访问的表排查问题时可能需要换 dba_ 开头的视图。SELECT tc.table_name, tc.comments AS table_comment, cc.column_name, cc.data_type, cc.data_length, cc.nullable, cm.comments AS column_comment FROM user_tab_comments tc JOIN user_tab_columns cc ON tc.table_name cc.table_name LEFT JOIN user_col_comments cm ON cc.table_name cm.table_name AND cc.column_name cm.column_name WHERE tc.table_type TABLE ORDER BY tc.table_name, cc.column_id;Oracle 的 user_tab_columns 取不到系统表但 V8.1 业务表足够用。data_length 对 varchar2 表示字节数对 CLOB 这种类型会显示一个固定值不代表实际数据长度。comments 为空的概率在 Oracle 环境中尤其高后面避坑章节会专门说怎么补。3.4 导完先核对三件事表数量、注释缺失率、主键第一件事是表数量。一个 V8.1 业务库通常在几百张如果只有一两百张大概率连的不是生产业务库或者漏了 schema。第二件事是注释缺失率。新建或升级后的库注释缺失率不会太高如果大面积缺失说明建表脚本本身没带 COMMENT后面需要人工补。第三件事是主键前面三条 SQL 都没导主键需要单独导一份改表和更新时用来定位唯一记录。MySQL 下主键信息这样取SELECT tc.TABLE_NAME, kcu.COLUMN_NAME FROM information_schema.TABLE_CONSTRAINTS tc JOIN information_schema.KEY_COLUMN_USAGE kcu ON tc.CONSTRAINT_NAME kcu.CONSTRAINT_NAME AND tc.TABLE_SCHEMA kcu.TABLE_SCHEMA WHERE tc.CONSTRAINT_TYPE PRIMARY KEY AND tc.TABLE_SCHEMA seeyon_v81 ORDER BY tc.TABLE_NAME, kcu.ORDINAL_POSITION;这个结果可以单独存一列也可以作为“主键字段”字段合并进字典表里。不建议跳过主键V8.1 很多业务表是逻辑主键加业务主键混合主键字段能帮你快速理解一张表在关联关系里的角色。4. 对着数据字典找业务表组织、流程、自定义表单的核心拆解4.1 组织三件套org_organization、org_department、org_member怎么关联组织模型是几乎所有业务表的关联枢纽。org_organization 存的是公司级组织单元org_department 存部门org_member 存人员。V8.1 里部门本身也是一种组织单元所以 org_department 和 org_organization 之间有父节点字段形成树结构。org_member 里的关键字段是 id、name、login_name、org_department_id、del_flag几乎所有业务表的 creator_id、initiator_id、owner_id 都指向 org_member.id。三张表关联的常见写法是SELECT m.login_name, m.name AS member_name, d.name AS dept_name, o.name AS org_name FROM org_member m LEFT JOIN org_department d ON m.org_department_id d.id LEFT JOIN org_organization o ON d.org_organization_id o.id WHERE m.del_flag 0 AND m.enabled 1;这里的 del_flag 含义各项目可能有差异一般 0 表示有效1 表示删除但建议先从字典里确认字段注释。enabled 可能不叫这个名字有些环境叫 status取值也不一致。用 LEFT JOIN 是因为 V8.1 里存在用户已离职但部门被删的情况内连接会直接丢掉这些历史记录影响统计。4.2 流程和表单中间还隔着一张关系表flow_form_relationV8.1 的表单和流程是两套引擎。表单定义和实例在 form_ 下流程定义和实例在 flow_ 下flow_form_relation 是它们之间的桥。查流程审批记录时通常要先在 flow_instance 里拿到流程实例 id再到 form_form_inst 里找对应的业务数据主键。一个流程定义可以绑多张表单版本所以 flow_form_relation 会返回多行。使用时要通过版本号或者 valid_flag 过滤到当前生效的那条否则会出现同一个流程 ID 对应多条表单 ID 的情况。数据字典里 flow_form_relation 的字段注释一般能看出哪个是流程 ID、哪个是表单 ID、哪个是状态位拿到后先做一次去重校验。4.3 自定义控件的字段不在字典里form_data_开头的动态表才是本体这是新手最容易卡住的地方。V8.1 表单设计器里的自定义控件实际存储方式不是“一个控件对应一个业务名字段”而是动态列。你在界面拖一个日期控件命名为“申请日期”提交后它在数据库里不叫 APPLY_DATE而是 DATE_0004 之类文本控件可能是 CLOB_0008数字控件可能是 NUMBER_0012。控件类型前缀对应存储类型后缀是控件在表单里的注册顺序。数据字典能告诉你 form_data_xxx 有哪些列但不会告诉你 DATE_0004 就是“申请日期”。我一般是先到 form_form_def 表里找到表单定义记录把它的设计模型大字段导出里面会有控件 name 和字段 ID 的映射关系再整理成一张“控件名-列名”对照表。定位表单定义记录用这样一条 SQLSELECT def_name, model_xml FROM form_form_def WHERE def_name LIKE %申请%;model_xml 在 MySQL 里一般是 LongText在 Oracle 里是 CLOB直接用客户端打开内容搜索 DATE_0004能看到对应控件的显示标题。这个步骤只能手工做一次做完后把映射表存成 Excel 或配置表后续写报表 SQL 直接查询不再每次翻设计器。4.4 一个可直接改的查询例子表单提交记录带出发起人和部门把前面几张表的关联关系串起来最典型的场景是“某个表单实例列表显示发起人和部门”。SELECT f.subject AS 表单标题, m.name AS 发起人, d.name AS 所属部门, f.create_time AS 提交时间 FROM form_form_inst f LEFT JOIN org_member m ON f.creator_id m.id LEFT JOIN org_department d ON m.org_department_id d.id WHERE f.state 20 AND f.create_time 2025-01-01 ORDER BY f.create_time DESC;state20 只是示例值不同客户环境里“已提交”可能对应别的数值需要从数据字典或界面列表反查。create_time 的字段名也可能叫 create_date。这个 SQL 骨架能复用到很多场景替换表名和关联字段后就是一张简单的业务查询模板。如果发现 LEFT JOIN 查出来很多 NULL 发起人优先检查 creator_id 是否指向 org_member.id而不是别的字段。5. 使用V8.1数据字典的五个避坑场景查空值、动态字段、流程变量、注释丢失、归档表5.1 按字典字段查出来全是NULL先确认字典版本与数据库实例对得上现象SQL 没语法错误关联条件看起来也对但查出来的某一列全是 NULL。原因最常见的是数据字典来自别的环境。V8.1 实施机器上常存在多个库比如 seeyon、seeyon_v81、seeyon_backup你从 A 库导出的字段名去连 B 库查询B 库根本不存在这个字段SQL 却因为动态条件没报错。另外有些字段在 V8.1 新版里改过名旧名字在字典里仍有但新库已经不再维护这个字段的值。解决在查询连接的那个数据库上重新执行第 3 章的导出脚本确认表名和字段名完全一致。再做一次快速校验用 count(字段) 和 count() 对比如果 count(字段) 远小于 count()说明该字段大量为空要么是字段维护逻辑不同要么是关联键写错。5.2 自定义表单的“DATE_0004”列名控件映射在字典里只能看到一半现象数据字典里能找到 form_data_ 表但所有列名都是 DATE_0004、NUMBER_0008 这种序号根本不知道哪一列是“申请日期”。原因动态表结构由控件注册顺序决定同一个控件在不同表单里可以是不同序号字典无法直接表达业务名称。解决去 form_form_def 的设计模型里找映射关系把控件名和列名做成一张独立的“表单字段映射表”。这个映射表要按表单维度维护因为不同表单的序号会重复。建议在项目配置里用 Map 结构管理比如 {DATE_0004: 申请日期, NUMBER_0008: 申请金额}写报表时先查这个 Map再拼 SQL。5.3 流程变量在表里搜不到去CLOB或XML字段里找而不是猜表名现象按数据字典逐表找会签意见、分支条件始终找不到独立列。原因V8.1 的流程变量并不是全部落成独立列一部分以序列化对象存在大字段里列名可能叫 variable_data、process_xml 或类似名称。字段类型是 CLOB、LongText、NVARCHAR(MAX)字典里能看到字段名但看不到具体内容结构。解决先在上一步导出的字典里筛出所有 CLOB/Text 类型的列再抽样几条数据用编辑器搜索关键词比如发起人姓名或者金额字段名。确认结构后如果要写进 SQL 做条件过滤Oracle 可以用 DBMS_LOB.instrMySQL 可以用 LOCATE但大表上性能很差建议把这些字段抽取到临时表后再过滤。5.4 字段注释大面积为空手工补一张业务映射表现象导出的字典里很多表和字段的注释都是 NULL。原因V8.1 部署时使用的建表脚本本身没有 COMMENT或者从老版本迁移时注释丢失。Oracle 环境尤甚informationschema 里没有注释user_col_comments 也是空的。解决用实施文档加界面字段名人工补一张“补充字典表”结构就是三列表名、字段名、业务含义。每次写 SQL 遇到无注释字段就补一行不用一次性补完。这张表放 Excel 或独立配置库都行但不要直接改业务库的 COMMENT因为部分数据库支持但升级脚本可能会重置。把补充表作为数据字典的附属文件联查时先看原始字典再看补充表。5.5 跨年统计少数据归档表和当前表要一起查现象统计去年下半年的数据总数总是比 OA 界面里看到的少。原因V8.1 存在历史数据归档机制。流程结束超过一定时间后流程实例、表单实例会被移动到带 history 或 his 后缀的归档表中当前表只保留近期数据。你从数据字典导出的表列表里通常能看到 flow_instance_history、form_form_inst_history 这类相邻表名。解决统计时把当前表和归档表用 UNION ALL 合并。前提是两张表结构一致先核对列名再写合并查询SELECT subject, create_time FROM flow_instance WHERE create_time 2024-01-01 UNION ALL SELECT subject, create_time FROM flow_instance_history WHERE create_time 2024-01-01;如果两张表结构不一致就只取共同字段避免 UNION 报错。这个坑在月底、年底统计时最容易踩建议在数据字典里把 history 后缀的表单独标记一列方便月度任务一次选全。6. 把数据字典用起来生成实体字段映射升级后做结构diff6.1 用Python读取字典自动输出Java/C#的字段映射数据字典不只是给人看的还能直接输出成开发用的实体映射。我常用 Python 连一次 information_schema把表字段读出来按下划线转驼峰的规则生成 Java 属性名和类型省去手写 resultMap 的时间。import pymysql conn pymysql.connect( host10.0.0.8, userseeyon, password******, databaseseeyon_v81, charsetutf8mb4 ) cur conn.cursor() cur.execute( SELECT c.COLUMN_NAME, c.DATA_TYPE FROM information_schema.COLUMNS c WHERE c.TABLE_SCHEMA seeyon_v81 AND c.TABLE_NAME org_member ORDER BY c.ORDINAL_POSITION ) def snake_to_camel(name): parts name.split(_) return parts[0] .join(p.capitalize() for p in parts[1:]) for col, typ in cur.fetchall(): if typ in (varchar, char, text, clob): java_type String elif typ in (int, bigint, smallint): java_type Long elif typ in (decimal, number, numeric): java_type BigDecimal elif typ in (datetime, date, timestamp): java_type Date else: java_type Object print(f{col} - {snake_to_camel(col)} : {java_type})这段脚本输出的是“数据库列名 / Java属性名 / Java类型”三列映射改一下目标表名就能批量生成。实际项目中我会把结果输出成 MyBatis 的 resultMap 片段直接粘到 XML 里。注意连接参数要换成自己环境的地址密码不要写死在脚本里用环境变量或配置中心读取。6.2 版本升级后跑一次字典diff提前发现破坏性变更V8.1 小版本迭代或补丁升级后数据库结构可能发生变化。升级前导一份字典升级后再导一份用表名加字段名做 key 对比就能快速看到新增字段、消失字段和类型变更。我一般把这步加进升级验收清单里。def dict_key(rows): return {(row[0], row[1]) for row in rows} # (表名, 字段名) old_map dict_key(old_rows) new_map dict_key(new_rows) print(新增字段, sorted(new_map - old_map)) print(消失字段, sorted(old_map - new_map))这段逻辑只判断了字段存在性类型变更需要额外把 DATA_TYPE 也拼进 key。实际使用中“消失字段”比“新增字段”更值得警惕因为这意味着线上 SQL 可能因为列不存在直接报错。我现在的习惯是每个迭代开始前把当前环境的字典导出一次放进项目文档升级完再导一次做对比这两个导出的差异就是本次升级的数据库变更清单。以前拿到老 V8.1 环境总想找建表语句后来发现直接拿字典比对着业务查更踏实。希望帮到你。本文还有配套的精品资源点击获取