如何構建變更跟蹤系統 - 不是審計系統

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觸發器的使用。在這個過程中它們可以非常有效和有效。