中西方的两种设计哲学-驰骋BPM表结构设计深度解析_对比Flowable与Camunda

一张表承载业务与流程：驰骋 BPM 二十年表结构设计之道

—— 对比 Flowable / Camunda 的效率、可理解、可扩展与可配置四维解析

中西方的两种设计哲学-驰骋BPM表结构设计深度解析_对比Flowable与Camunda

引言：两种设计哲学

工作流引擎的表结构设计，本质上是在回答一个问题：流程数据与业务数据，应该放在一起，还是彻底分开？

• Flowable / Camunda（源自 Activiti，欧洲开源生态）选择了典型的 BPMN 2.0 引擎路线：流程引擎只管"流程运转"，业务数据通过 BUSINESS_KEY_ 或流程变量（ACT_RU_VARIABLE）与外部业务表松耦合关联。
• 驰骋 BPM（CCFlow / JFlow，中国本土 20 余年持续演进）选择了另一条路：流程数据与业务数据同表存储、元数据驱动、面向中国审批场景深度优化。

这不是"谁更先进"的简单判断，而是两种产品基因与目标市场不同所导致的设计取舍。本文从驰骋表结构的可取之处出发，与 Flowable / Camunda 做系统对比，并从效率、可理解、可扩展、可配置四个维度给出结论。

一、驰骋 BPM 表结构总览

驰骋的表体系可按职责分为三层，命名直观、前缀统一：

1.1 核心设计：PTable —— 流程与业务同表存储

每条流程在 WF_Flow 中配置 PTable（流程数据存储主表），默认为 ND{流程编号}Rpt。这张表同时承载：

流程信息字段（引擎自动维护）：

业务字段（设计器配置）：

表单设计器在 Sys_MapAttr 中定义的字段，直接映射为 PTable 的物理列，如金额、事由、附件等。

这意味着：查一条请假记录，一次 SELECT 就能拿到业务内容和流程状态，无需跨多张引擎表 JOIN。

1.2 流程实例注册表：WF_GenerWorkFlow

WF_GenerWorkFlow 是所有流程实例的"总台账"，字段设计充分考虑了中国企业的查询习惯：

• Starter / StarterName：发起人编号与姓名（冗余存储，列表免 JOIN）
• FK_Dept / DeptName：部门编号与名称
• TodoEmps / TodoEmpsNum：当前待办人列表与人数
• Emps：全部参与人
• BillNo：单据编号（中国企业极常见的单号体系）
• WFSta + WFState：双层状态设计，兼顾统计汇总与精细控制
• OrgNo / DomainExt：多组织 / 多租户 / 多子系统隔离
• AtPara：运行期扩展参数（@Key=Value 格式，免改表即可扩展）

1.3 工作者表：WF_GenerWorkerList

待办任务的核心表，采用三主键设计：(WorkID, FK_Emp, FK_Node)。

• 同一流程实例、同一节点、不同处理人各有一条记录
• 冗余 NodeName、EmpName、FK_Dept，列表查询不依赖维度表
• 支持 IsRead（已读未读）、IsPass（合流节点通过状态）、WhoExeIt（人工/机器/混合执行）
• AtPara 扩展参数，节点级运行数据灵活挂载

1.4 待办视图：WF_EmpWorks

WF_EmpWorks 不是物理表，而是将 WF_GenerWorkFlow、WF_GenerWorkerList、WF_CCList（抄送）通过 UNION 组装的标准视图，统一输出"我的待办"所需字段。

业务人员无需理解底层分表逻辑，直接查 WF_EmpWorks WHERE FK_Emp='zhangsan' 即可。

1.5 元数据驱动：Sys_MapData + Sys_MapAttr

驰骋的表单不是写死在代码里的，而是：

1. Sys_MapData 定义表单/实体（含 PTable 物理表名）
2. Sys_MapAttr 定义每个字段的类型、长度、控件、枚举绑定、外键绑定
3. 设计器保存时自动 ALTER TABLE 增删物理列

这套元数据体系让业务顾问 / 实施顾问无需改代码即可调整字段，是中国政企、制造业信息化项目的典型交付模式。

1.6 流程轨迹：WF_Track

独立轨迹表记录每次流转的动作类型、起止节点、处理人、意见、耗时等，支持中国审批场景所需的完整审计链路（退回意见、会签记录、转办记录等）。

二、Flowable / Camunda 表结构概览

Flowable 与 Camunda 同源（均源自 Activiti），表名均以 ACT_ 为前缀，按用途分为：

2.1 核心特征

1. 流程变量中心化：业务数据以 Key-Value 形式存入 ACT_RU_VARIABLE（运行时）和 ACT_HI_VARINST（历史），类型通过 TYPE_ 字段区分（string、long、double、serializable…）。
2. 运行时数据生命周期短：流程结束后，ACT_RU_* 表中的记录被清除，只保留 ACT_HI_* 历史表。
3. 业务数据外置：引擎通过 BUSINESS_KEY_ 关联外部业务表，引擎本身不持有业务字段的物理列。
4. 表数量多、关系复杂：完整部署通常涉及 25～70+ 张表（含 Job、Event、IdentityLink 等），学习曲线陡峭。
5. 字段命名英文化、抽象化：PROC_INST_ID_、EXECUTION_ID_、TASK_DEF_KEY_ 等，对非引擎开发者不够友好。

三、四维对比分析

3.1 效率（查询与写入性能）

结论（效率）：

• 读多写少、报表密集的中国政企场景，驰骋的"宽表 + 冗余"模型在列表查询、统计分析上效率更高，SQL 可直接交给 DBA 优化。
• 超高并发、短生命周期流程场景，Camunda 的运行时表自动清理策略在写入峰值上更有优势。
• 驰骋通过 FlowEmps、StarterName 等冗余字段，以空间换时间，这在中国项目"领导要看报表、审计要查台账"的需求下是务实选择。

3.2 可理解性（开发与运维友好度）

结论（可理解）：

驰骋的表结构对中国实施顾问、业务分析师、DBA 更友好——不需要先学完 BPMN 引擎内核，就能写 SQL 出报表。Flowable/Camunda 更适合深度定制引擎行为的 Java 架构师，但对业务人员是黑盒。

3.3 可扩展性（字段与能力扩展）

结论（可扩展）：

驰骋的扩展路径是**“配置优先”**：字段扩展走元数据，能力扩展走流程设计器节点属性。这与中国企业"实施期频繁变更、上线后持续调优"的节奏高度匹配。

Flowable/Camunda 的扩展路径是**“代码优先”**：强大、灵活，但每次业务变更往往涉及开发排期，对"快上线、快调整"的中国互联网和政务项目不够敏捷。

3.4 可配置性（实施与交付）

结论（可配置）：

驰骋从表结构层面就把**"可配置交付"刻进了基因：顾问在后台配表单、配流程、配报表，三张皮合一。Flowable/Camunda 是优秀的流程执行内核**，但表单、报表、组织、单据号等中国式需求需要大量外围集成。

四、典型场景对比：中国企业最关心的五个问题

4.1 "我的待办"怎么查？

驰骋：

SELECT * FROM WF_EmpWorks WHERE FK_Emp = 'zhangsan' AND WFState = 2

一个视图，字段含标题、发起人、部门、节点、到达时间，直接渲染列表。

Flowable / Camunda：

SELECT t.*, e.BUSINESS_KEY_
FROM ACT_RU_TASK t
JOIN ACT_RU_EXECUTION e ON t.PROC_INST_ID_ = e.PROC_INST_ID_
WHERE t.ASSIGNEE_ = 'zhangsan'

标题、部门、发起人等需在 BPMN 中设为变量，或从外部业务 API 补充。

4.2 "我发起的流程"怎么统计？

驰骋：

SELECT * FROM ND101Rpt
WHERE FlowStarter = 'zhangsan' AND WFState > 0

或在总台账：

SELECT * FROM WF_GenerWorkFlow
WHERE Starter = 'zhangsan' AND WFState = 3

Flowable / Camunda：

SELECT * FROM ACT_HI_PROCINST
WHERE START_USER_ID_ = 'zhangsan' AND END_TIME_ IS NOT NULL

只能拿到流程实例元数据，业务字段需另查。

4.3 “按部门统计本月采购金额”

驰骋：

SELECT FK_DeptName, SUM(PurchaseAmount) AS Total
FROM ND205Rpt
WHERE WFState > 0 AND FlowStartRDT LIKE '2026-06%'
GROUP BY FK_DeptName

一条 SQL，业务字段是真实列，可走索引。

Flowable / Camunda：

需要从 ACT_HI_VARINST 中按 NAME_='purchaseAmount' 取 DOUBLE_，再与流程实例关联，性能和可维护性均不如宽表方案。

4.4 会签、加签、退回

驰骋在 WF_GenerWorkFlow 中有 HuiQianTaskSta（会签状态）、TodoEmps（多人待办），WF_Track 记录每次动作类型（退回、转办、会签等），表结构为中国式审批"多人并行、主持人汇总、退回重走/退回不重走"等场景预留了字段。

Flowable/Camunda 通过 BPMN 多实例（Multi-Instance）实现会签，灵活但配置复杂，退回策略需在网关和监听器中编码，实施门槛更高。

4.5 国产化信创

驰骋在 SQL 脚本层面对达梦、人大金仓等国产数据库有专门适配（如 UpdataCCFlowVerForKingBase.sql），表结构使用通用 SQL 类型，政企信创项目落地经验丰富。

五、综合结论

5.1 驰骋 BPM 表结构的核心可取之处

1. 流程与业务同表（PTable）：消除跨表 JOIN，报表 SQL 极简，这是中国信息化 20 年实践证明最高效的模型。
2. 元数据驱动（Sys_MapData / Sys_MapAttr）：表单即表结构，配置即交付，实施周期短。
3. 冗余换性能（Name 字段、FlowEmps、TodoEmps）：待办列表、我发起的、我参与的查询无需多表关联。
4. 双层状态（WFSta + WFState）：兼顾宏观统计与微观控制，贴合中国审批习惯。
5. AtPara 扩展参数：不改 DDL 即可挂载运行期数据，平衡灵活性与稳定性。
6. WF_EmpWorks 标准视图：屏蔽底层复杂性，对外提供统一待办 API。
7. 原生多组织（OrgNo）与中国式能力字段：少造轮子，多配参数。

5.2 Flowable / Camunda 的优势领域

1. BPMN 2.0 标准合规：国际化项目、与欧洲企业系统对接。
2. 运行时表自动清理：超高并发短流程场景，运行时数据不膨胀。
3. 开源生态与社区：全球开发者、Spring Boot 深度集成、微服务架构友好。
4. 引擎内核可插拔：适合"只要流程引擎、表单报表自建"的纯技术团队。

5.3 为什么驰骋更适合中国场景

六、结语

表结构设计没有绝对的"最优"，只有与目标场景最匹配。

Flowable 和 Camunda 代表了国际标准、引擎纯粹、开发者友好的路线，在全球化微服务架构中表现卓越。

驰骋 BPM 用 20 余年的中国项目实践，走出了一条**"流程即业务、配置即交付、SQL 即可报表"的路——它的表结构不是学术意义上的范式化典范，却是中国企业信息化最高效、最可理解、最易交付**的务实之选。

如果你正在为中国政企、制造、金融、能源等行业选型工作流平台，且团队以实施顾问和业务分析师为主力，驰骋的表结构设计会让你在第一天就感受到：这套系统，是中国人自己做的。

附录：核心表对照速查

本文基于驰骋 BPM（CCFlow）源码与 SQL 脚本分析，结合 Flowable / Camunda 官方数据库文档整理。
撰写日期：2026 年 6 月