如何构建变更跟踪系统 - 不是审计系统

Question

我有一个要求，即需要在库存中捕获数据更改（而不是审计）和生命周期状态。

技术： java的，甲骨文的Hibernate + JPA

对于数据的变化，我们已经考虑到要被监控的数据元素的列表。如果元素发生变化，我们要通知给定的第三方供应商。我想要做的就是将这个通用服务提供给我们当前和未来的第三方供应商。

我们不关心是谁进行了更改，或者新的价值是什么改变了。

思想是我们的应用程序的数据层会在每个数据元素上使用注释。如果该数据元素发生更改，则会将消息放入队列中。消息bean然后会读取队列并在表中创建一个条目。

表看起来像下面这样：

Table Name: ATL_CHANGE_TRACKER 
Key columns 
INVENTORY_ID   Inventory Id of the vehicle 
SALEEVENT_ITEM_ID  SaleEvent item of the vehicle 
FIELD_CHANGED_ID  Id of the field that got changed or action. Link to subscription 
UPDATE_DTM   Indicates the date time when change occured. 

对于一个给定的库存，我们可以在这台长达200项（监控跨多个表200场）。

然后，给定第三方的守护程序将根据它已订阅的字段（可能是所有字段）从此表读取该表。然后，它会读取每个表需要创建发送给第三方的消息。将数据的提供者和数据的用户分开。

识别字段/可用

Table Name: ATL_FIELD_ACTION 
Key columns 
ID 
NAME     Name of the field/action - Example Color,Make 
REC_CRE_TIME_STAMP 
REC_CRE_USER_ID 
LAST_UPDATE_USER_ID 
LAST_UPDATE_TIME_STAMP 

认购表，如果第三方XYZ公司有兴趣在60场操作的列表，在60场将被映射到这个表。

ATL_FIELD_ACTION_SUBSCRIPTION 
Key columns 
ATL_FIELD_ACTION_ ID  ID of the atl_field_action table 
CONSUMER     3rd Party Name 
FUNCTION     Name of the 3rd Party Transmission that it is used for 
STATUS 
REC_CRE_TIME_STAMP 
REC_CRE_USER_ID 
LAST_UPDATE_USER_ID 
LAST_UPDATE_TIME_STAMP 

第二部分是会有哪个将需要也将条记录库存的生命周期操作。在这种情况下，当库存状态发生变化时，消息将被放置在同一队列中，并且该条目将被输入到同一个表中。

再次，守护进程将已经订阅了这些国家和将收集的那些它感兴趣的

这里的目标是不是有业务层/数据层关心谁想要的数据 - 只是它需要提供，所以感兴趣的人可以得到它。

不知道是否有人做过这样的事情 - 任何问题 - 现成的 - 开源解决方案来做到这一点。

Answer 1

对于关于该主题的高层次讨论，我建议您阅读Martin Fowler的this article。

它听起来像你有一次写入，读取多种类型的数据，它可能会产生大量的数据，并且数据对于不同的客户端是不同的。如果你问我，这听起来可能是一个利用NOSQL数据库或者破解你的Oracle数据库充当NOSQL数据库的好地方。请参阅here以了解某人如何使用MySQL进行的讨论。否则，你可以看看创建一个“不可变的”数据库表，并让Hibernate在每次执行更新时写入新记录，如here所述。

Answer 2

夫妇的事情。

首先，你自己做所有这些工作。 JPA/Hibernate生命周期侦听器虽然具有发生更新时的事件，但未传递“旧”对象和“新”对象。所以，你将不得不跟踪使用其他方法改变字段。

其次，再次使用生命周期监听器时，要小心它们，因为事务状态有点模糊。至少在Glassfish/EclipseLink上，我使用生命周期侦听器中的JPA或JMS出现了“奇怪”的问题。只是奇怪的行为。我们去了一个非事务性的队列，以捕获我们从生命周期事件中追踪的所有信息。

如果在自己的事务上提交的更改数据是可接受的，那么值就是将数据推送到更快的内部队列（可以提供将它发布到MDB的侦听器）。这只会让您的交易“带外”进行审计，为您提供更好的交易吞吐量。但是，如果您需要使用相同的交易承诺更改信息，则这不起作用。例如，您可以在队列中放入某些内容，然后可以回滚事务（无论出于什么原因），将更改显示在发生事件的队列中，而事实上它失败了。这是一个潜在的问题。

但是，如果您发布了大量的审计信息，那么这可能是一个问题。

如果审计信息的寿命短（相对于其余数据），那么您应该尽力剔除审计表，它们会变得非常大。

另外，如果可行，不要忽视DB触发器的使用。在这个过程中它们可以非常有效和有效。