关于业务系统可审计设计类型可能包括：日志（log）、快照（snap）、记录（record）。

其中：

（1） 日志（log）用于记录对系统资源操作记录，为审计何人何时做过何事提供依据，但不作为业务逻辑处理的依据。具有操作细粒度，数据粗粒度。所谓操作细粒度是指记录对资源的任何操作过程记录，包括关键操作和非关键操作，记录的主体包括何人、何时；所谓数据粗粒度，是指对记录中何事的描述仅为一段文字描述，而不对具体字段的变化进行单独的记录，因此也就不能够为业务逻辑处理提供依据。

根据业务范畴的不同，可以提供不同粒度的日志：系统级日志（某个子系统的操作记录）、功能级日志（某个功能模块的操作记录）、数据级日志（某个具体资源/表的操作记录）。

考虑到业务的应用的不同，应该对日志加以类型标记，比如：是否关键操作：一般操作（非关键的操作）、关键操作（引起数据变化的操作、通常会有镜像数据的生成）；是否审批操作：在工作流节点中的关键操作。

（2） 快照（snap）:用于记录某条数据记录发生某个关键操作变化时，通过复制一条数据记录的快照把变化前的数据记录存储下来，字段可以是所有的字段也可以是根据业务需要仅记录关键字段和易变字段。因为数据的完整性，因此可以为操作的undo提供了依据。具备操作粗粒度（仅记录关键操作）、数据细粒度（字段完整）。

优点：提供了数据完整性；

缺点：

（a）从何人何时何事的角度看，完整的记录了何事，但对何人、何时需要另外加以存储，另外因为操作粒度仅包括了关键操作，对过程支持不足，需要通过Log或其他的系统加以补充。

（b）在反映变化时，需要通过前后相邻的快照来找到变化了的业务内容。关于业务操作的类型定义自身不容易体现，需要Log来加以反映。

（c）snap在时间轴上解决了现在、过去的数据支持，但对将来支持不够，比如某一个业务变化，需要记录希望改变的内容，但需要先进行流程审批，审批之前依然要根据现有的业务进行，属于先申请，经过审批后才可以应用新的数据记录。可能的操作方式为：先提供一条新的表示将来的数据；对数据进行审批，审批如果通过，则现行数据先生成一条snap记录（过去），然后用新数据覆盖现行数据。

（3） 记录（record），准确说应该为变化记录，就是对在一条变动记录中，同时记录下变化前和变化后的变化了的数据内容。从何人何时何事的角度来看，同snap一样，也是用于满足对何事的记录，并满足部分（但不完整）的何人何时记录。

通常可以有两种记录方式：

（a） 将表中所有易变字段和关键字段都计入一个表中，所有易变字段都包括变化前后的记录（变为两个字段pre-和post-）；优点是可以适应多种业务数据的变化支持，缺点是冗余字段多；

（b） 如果业务变动较少，可以根据业务变化的不同，增加不同的业务变化的前后数据的支持；优点是冗余数据少，缺点是如果业务变动类型多时，会需要增加不同的表来支持，另外对业务变化也支持不够。

根据以上的分析，对可审计日志提出如下建议：

（1）所有的写操作（部分读操作）生成操作日志。可以有不同的粒度：系统级日志、功能级日志、数据级日志。

（2）关键操作，要对原记录生成snap或者record。

如果用snap：如果能够明确识别易变字段，则生成易变字段snap，但如果不容易识别，则提供完整数据；

如果用record：如果不确定业务变化类型的数量时，则对所有易变字段进行变化前后的记录；如果能够确定并且类型较少，但不同类型的工作流程差异较大时，而且有其他衍生资源或逻辑时，建议采用不同的业务分别记录各自不同的变化记录。