常用的设计方案有两种，个人推荐方式二。
直接查询工作流原生的act_ru_task和act_hi_task，这种方式如果涉及到多个流程，并且每个流程查询出来的数据差别比较大时此时查询SQL可能会比较复杂，难以维护。
创建待办表专门用于待办已办查询，这种方式待办已办查询非常简单，但需要维护数据。
wf_todo_list: 每个节点一条数据，会签也只存一条数据，会签详情单独放一张表。
| 字段名 | 数据类型 | 描述 |
|---|---|---|
| id | int | 主键自增id |
| proc_inst_id | varchar(50) | 流程实例id |
| task_id | varchar(50) | 任务id |
| process_no | varchar(50) | 流程编号：全局唯一，流程字母简称+唯一值，例如LP36942174069834 |
| title | varchar(255) | 流程标题 |
| process_type | smallint | 流程类型 |
| node_name | varchar(50) | 节点名称 |
| assignee | varchar(50) | 审批人用户id |
| create_time | datetime | 创建时间 |
| approve_time | datetime | 审批时间 |
| approve_result | varchar(10) | 审批结果 |
| done_type | smalint | 是否已做（0：待办，1：已办） |
| button_type | smalint | 按钮类型（1：办理complete，2：撤回rovke，3：退回return，4：终止stop） |
| node_type | smalint | 节点类型(1:用户任务节点，2：会签节点) |
| ext | json | 扩展参数 |
| remark | varchar(255) | 备注 |
| last_todo_id | int | 上一节点id |
wf_todo_countersign：会签详情，一条wf_todo_list对应多个wf_todo_countersign。
| 字段名 | 数据类型 | 描述 |
|---|---|---|
| id | int | 主键自增id |
| todo_id | int | 外键wf_todo_list.id |
| proc_inst_id | varchar(50) | 流程实例id |
| task_id | varchar(50) | 任务id |
| assignee | varchar(10) | 审批人用户id |
| create_time | datetime | 创建时间 |
| approve_time | datetime | 审批时间 |
| approve_result | varchar(10) | 审批结果(0：不同意，1：同意) |
这两张表单的数据只需写一次就行，借助全局监听器，通过在业务方法中通过全局变量或者局部变量来作为中间桥梁传递必要的业务参数。