关于业务数据版本化管理的探讨

大家都知道功能完善的wiki都会有历史版本记录，能够查看历次变更的内容。其实企业里的业务数据也需要有类似的功能，能够允许用户查看业务数据的历次修改。特别是在我们的ERP系统中，由于集合了工作流，因此经常出现用户会不断的在被驳回的业务单据上进行修改。修改多了，用户就会想要查看他历次的修改内容。

不知道大家在平时的开发过程中，是否也有遇到类似的需求，大家又是怎么解决的。我在这里说一下自己的思路，看看是否合适。

我想到两种方法，分别是采用数据库和采用subversion。

1、采用数据库。
需要设计一张变更表，比如 biz_changes 表，字段大致如下：

CREATE TABLE biz_changes
(
  id integer not null primary key, // 主键
  biz_type text NOT NULL, // 业务数据类型
  biz_id integer not null, // 业务数据id
  change_time integer NOT NULL, // 变更时间
  author text,  // 变更者
  field text NOT NULL, // 业务数据发生变更的字段或属性
  oldvalue text,   // 发生变化前的值
  newvalue text   // 发生变化后的值
)

通过这张表，可以将所有的业务数据的变化都记录下来。缺点是所有的业务数据的变化记录在一张表内，记录数的增加客观，会影响查询效率。当然也可以根据不同的业务数据类型，创建多个变更表，但这样后期维护是否会比较麻烦？

这里还有一个疑问是biz_type到底是记录业务数据对应的模型名称好，还是记录业务数据对应的数据库表名好？如果是模型名称，那所有的变更记录都需要在业务逻辑中实现，优点是可移植性高，缺点是侵入业务逻辑。如果是数据库表名，那变更记录可以由数据库的触发器来实现，优点是对业务逻辑的侵入最小，缺点是难于维护。对了，还可以通过AOP来实现变更的记录，这样就解决了侵入业务逻辑的问题。

采用这种方式直观，缺点是变更变化需要自己来维护，对于变更的汇集、查询，以及变更差异的显示都需要自己来实现，有重复造轮子的嫌疑。

2、采用subversion
将所有的业务数据以XML的形式保存下来(当然，事先需要先定义好XML Schema）。同时用subversion来创建一个svn仓库，用来保存这些业务数据。我想了一下，可以将业务数据对应的模型名称作为目录，业务数据的记录编号（与数据库的记录编号一致）作为文件名保存。当一个新的业务数据持久化后，就新增一个svn文件，若是修改，则提交对应编号的文件。

这样的优点是减轻了数据库的负担，同时变更的汇集、查询都不用自己来实现，直接调用svn相关的api即可。缺点暂时还没想到。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
对了，除了记录变更历史，还需要展现变更历史。最友好的展现方式就是针对不同类型的业务数据，编写特定的展现界面。但这个工作量浩大，是否可以用一个展现界面就能很形象的将这些变更历史展现出来？

应该还有很多我还没想到的问题。不知道大家有什么意见和想法，欢迎交流沟通！