Activiti-1-DBSchema
    今天先说说Activiti的底层数据库表结构吧
    大家都知道，现代的编程，因为要保存所谓的状态，呵呵，所以出了很多名词；例如：持久化等等。这里我不想精确讨论什么是所谓的持久化，或者这个化那个化的，我只想说，作为一个程序员，需要绝对高度的抽象思维，但比这个更重要的，是你在高度抽象后能够把你心里或者脑海里那幅虚拟的视图可以形象的表达出来，可以让知识传承，可以让你脑海里的那幅视图尽量保持原版的传递给更多的人，这，才是真功夫！ 所以我想说，持久化，不是啥高深玩意，就是把你程序中非要保存不可的数据（就是所谓的状态等高深名词）能找个地儿，用个方法存起来；以便日后能继续找来接着用。至于说存在数据库还是所谓的XML文件，或者什么其他形式，你定；存在硬盘、磁带还是什么Flash中，你定；有牛x的，现在就是存在内存中 呵呵
    那为什么今天把Activiti的后台持久化所需的数据库dbschema拿出来先讲呢。我以为，所有程序员都是一个天生的良好习惯 -- 那就是，爷就是不满足知其然，就是想知其所以然。好事儿，但是仅从Activiti这种工作流引擎来看，我觉得，先将其底层的数据库存储结构搞明白，更容易让你知其所以然。所以 先说说其结构。
    截止到5.0-alpha2版，其数据库表结构如下图所示，供12张表；Btw：Activiti的表结构目前还处于不稳定状态，可能时时都会改变，先就着目前情况说。

    1.Act_Property表。属性数据表。存储整个流程引擎级别（这句话理解起来有些抽象哦，等你读完Activiti的源码或者使用过Activiti或jBPM的同学们应该会理解深刻）的数据。如：当前整个应用的版本，数据库下一个ID号应该为多少等。 你可以忽略，它对你理解整个Activiti一点没影响。

    2.Act_Deployment. 这是张十分重要的表，用来存储你部署时需要被持久化保存下来的信息。如，你有一个需要部署的业务打包文件(ie:example.bar),那么这张表里将有一条记录，是这样的：10001，example.bar，2010-06-29;分别对应ID_,NAME_,DEPLOY_TIME_这三列。

    3.Act_ByteArray.这更是一张重要的表。它是用来保存我们部署时文件的大文本数据的。例如，我们的example.bar中的结构是这样的。
    example.bar
      -- processDef-1.bpmn20.xml
      -- processDef-2.bpmn20.xml
      -- form-inProcess-1.html
      -- form-inProcess-2.html
      -- logo.jpg
    那么程序完成部署逻辑后，Act_ByteArray这张表中将会增加5条记录；其中三个关键字段，NAME_ 存储对应文件的名称，String型；Deployment_ID_ 来自于父表Act_Deployment中的主键； Bytes_ 大文本类型，存储文本字节流

    4.Act_ProcessDefinition. 顾名思义，这张表用来存储你预先定义好的流程定义的信息。但是一点要注意，如果同一个流程定义文件被重复部署了两次（无论你是有意的还是无意的），那么这将导致在这个表里会出现两条记录，但是，这两条记录的Name_ Key_字段是相同的，ID_/Version_/Deployment_ID_这三个字段的值是不同的。（具体原因，看一下User Guild，或者后面我会解释的）

    5.写的太累了，自己都有点烦了。下面Act_Execution Act_task Act_TaskInvolement Act_Job Act_Variable这五张表。 这五张表在执行完所谓的”部署“逻辑后，是不会被填上任何值的。那什么时候这些表会被填充上值呢？ 当我们根据一个叫做ProcessService（在jBPM中，这个类是ExecutionService）的类，来真正启动（Start）一个流程时，这些表中才会被根据你定义的流程定义，填充上相应的记录。 一个不精确的比喻，在Activiti中，流程定义和流程执行实例，就像Java中的Class何Class Instance关系一样，根据一个流程定义，可以启动多个流程实例，供不同业务需求使用；一个类，当然可以有多个运行时实例，供不同需求使用。 需要多说一点，Act_TaskInvolement这张表直译过来就是，任务参与者，所以它存的是：和一个流程中，一个具体动作（Activity）相关的用户（User）和角色（Group）的信息，即：当前节点参与者的信息。其他的表，也可以顾名思义了吧，就是存和一个具体动作相关的参数以及作业的信息。  最后强调一点：这五张表有点像即擦即用的Flash存储介质哦。 什么意思，一个流程假设有多个动作（任务、节点......叫啥也行）组成，那么这五张表只是存储当前流程实例中，”活动（Active）行为“的相关数据，如果现在活动的行为已经从A节点流到B节点了，那么，与A节点相关的所有信息是会从这4张表（不包含Act_Execution，流程实例全部完成，相关记录才会删除；而不是一个动作完成）中被删除的！！！！

    唉，写了这么多，想想，如果一个人连jBPM或者Activiti都没有用过，连一个感性认识都没有的话，这么写实在还是太抽象了；唉 也必须承认，自己还是水平有限，真正写写才知道离自己定义的”深入浅出“的标准差太远了！！！
    但是毕竟写了，就先放在blog上吧，可供今后使用Activiti的朋友做一个中文对比，看看事实是不是这样。 
    最后了，希望能给喜欢知其所以然的朋友提供一点小小的先导吧。 哈，毕竟看源码看log分析表结构其实挺累的；但是知其所以然，又是必须的。
    有了这个铺垫，以后写点关于Activiti的源码解析，也算有基础了。哈