ClearQuest缺陷之History

      ClearQuest中每一个Entity都有一个特殊字段history，这是一个系统字段，设计Schema时不允许修改或删除。该字段能够记录用户对Entity的每一次修改，包括状态的变化、Action的Name，Action发生的时间以及执行Action的User等，在考察有谁更改过Entity时十分有用。

 

      然而，查看history时并不仅仅想知道有谁在什么时间对Entity做过什么样的Action，我们更想了解的是这个User到底改了哪些字段，以及这些字段的Value变化等信息，但是history字段无法提供这样的信息。

 

      在Schema中还有一些特殊的Entity，我们并不关心谁对它做过修改（比如这样的Entity由Schema自动生成，并不允许用户修改或仅允许特殊用户修改）。然而，即使是这样的Entity，都至少有一笔history记录，而且设计Schema是不允许把这个字段去掉，在使用时往往会占用很多不必要的空间。

 

      相比不必要的记录，history最大的缺陷还是不能反映到底User做过什么样的修改，而这些恰恰是我们所需要记录的。

 

      既然history无法记录修改的细节，我们就必须自己实现这个功能，思路是把每个字段的修改都记录下来并存入CQ，在我所开发过的Schema中，这样的记录称之为ChangeLog。实现ChangeLog有两种方案，一是给Entity增加一个Multiline String类型的字段，把ChaneLog转换问文本添加到这个字段，另一种方法是建立一种新的Entity，记录每一个字段的每一次改动，并把这种新的Entity用Reference List型字段关联到Entity。这两种方法各有优劣，用Multiline String不会增加数据库中记录的数量，但是不便于查询处理，尤其用代码根据ChangeLog处理时；增加新Entity的方法便于对ChangeLog的查询处理，但是大大增加了数据库中记录的数量。

 

      使用新Entity增加的记录与被记录的Entity的比例能达到十比一甚至二十比一，对于数据增长迅速的应用来讲记录ChangeLog的Entity的数量会相当可观。但是要命的问题还不在这里，每个Entity都至少有一笔history，而整个Schema中所有Entity的history在数据库中都共用一个表，那这个表将会变得庞大无比，会极大的影响CQ的速度。举个例子，我维护过一个CQ，其主Entity的数量有三百多万，ChangeLog则达到了五千多万，而history的数量则接近一个亿，与其他部门（数据量比较少）使用相同Schema的CQ相比，速度下降的非常明显，然而我们给这个大CQ使用的却是最好的硬件，对数据库做过大量的优化工作，即使如此，维持这个CQ的效率仍是一件令人非常头疼的问题。

 

      所以说，CQ中history机制设置的过于死板，即使不允许修改所记录的数据项目，也应该给Schema设计者去掉这个字段的权利。遗憾的是没有，CQ的开发维护人员不得不忍受这种死板带来的麻烦。