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

Question

我需要在库存中捕获数据更改（不是审核）和生命周期状态。

技术： Jave，Oracle，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数据库的好地方。有关如何使用MySQL进行此操作的讨论，请参阅here。

否则，您可能会看到创建一个“不可变”数据库表，并让Hibernate每次执行更新时都会编写新记录，如here所述。

Answer 2

夫妻俩。

首先，您可以自己完成所有这些工作。 JPA / Hibernate生命周期监听器虽然有更新发生时的事件，但您不会传递“旧”对象和“新”对象。因此，您将不得不使用其他方法跟踪哪些字段发生了变化。

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

如果在自己的事务上提交了更改数据是可以接受的，那么有价值就是将数据推送到更快的内部队列（可以提供将其发布到MDB的侦听器）。这只会使您的交易“带外”审核，为您提供更好的交易吞吐量。但是，如果您需要使用同一事务提交更改信息，则无效。例如，您可以在队列上放置一些东西，然后事务可能会回滚（无论如何），将队列上的更改显示出来，当它实际上失败时。这是一个潜在的问题。

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

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

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