如何版本動態業務對象/數據？

我們正在開發與業務相關的大型應用程序。你可以找到類似的一些ERP，CRM等這些應用如何版本動態業務對象/數據？

現在，我們有我們需要這些由用戶輸入進行版本的所有數據的要求。

例如：在某個時間點，用戶需要查看特定採購訂單的更改歷史記錄。

我要尋找一個非常通用的版本處理器（不是剛性），如果有的一些業務數據屬性得到改變它可以處理甚至案件。這個單一的版本控制處理程序應該能夠處理幾乎任何類型的業務對象/數據。

什麼是最好的編程/數據庫設計來處理這些。

任何想法或意見？

PS：我添加了一些編程標籤，因爲我希望程序員能夠娛樂此主題並給出他們的想法。

編輯：我正在尋找一個非常優化的方式，有點類似於存儲差異生物，而不是以序列化/傾銷的方式存儲對象。

來源

2011-10-17 linuxeasy

我刪除了仿製藥的標籤。請閱讀泛型標籤說明。 – Saintali

解決方案很大程度上取決於您的對象如何存儲在第一位。你在使用關係數據庫嗎？另一個基本點是如何使用版本化的對象？這只是一個日誌，還是你需要能夠像現在一樣呈現應用程序的舊狀態？ –

@Nicola Musatti - >是的，這將是一個關係數據庫。是的，我們需要能夠呈現舊國家。對象具有其屬性，甚至可以是子對象。 – linuxeasy

這可能只是採用purely functional懶數據結構的好時機。

簡而言之，這需要禁止你的對象的任何變異操作，即讓所有的對象實例immutable。然後重新設計所有改變現有對象的操作，在舊的對象上創建基於的新對象實例。

例如，讓您有一個Order實例，其中包含OrderItem的列表，您需要將特定的OrderItem添加到該列表中。你在這種情況下做的是創建Order的新實例用新列表替換其項目列表，而新列表又由cons將新的OrderItem創建爲舊列表。

讓我進一步說明的圖片，例如。試想對象的存儲（讓它是RAM或者關係型數據庫，任何東西）：

Address | Object | Created by --------+--------------------+------------------------------------------ 1000 | list of OrderItems | empty list constructor 1001 | Order | Order constructor, uses address 1000 ... 1300 | OrderItem | ... 1501 | list of OrderItems | cons of addr 1300 to addr 1000 1502 | Order | replace order_items in addr 1001 by addr 1501

以這種方式存儲數據的結構本身是持久性的（克里斯·奧卡薩基在此闡述了his thesis，例如）。您只需按照其創建歷史記錄即可恢復任何版本的對象;版本控制變得微不足道。請記住主要觀點：不要改變數據，而要創建新的實例。

來源

2011-10-25 14:55:09 ulidtko

如果你不是侵入性的（我認爲泛型與侵入性競爭），那麼我認爲你的選擇是做完整的序列化。在每個版本中，您只需拍攝對象的快照並將其序列化爲適合的任何內容。

如果您僅限於數據庫，請使用時間戳保存並將最新的時間戳記作爲當前時間戳記。儘管如此，我會避免將它僅僅視爲數據庫問題。你應該被允許序列化系統之類的部分結果，測試，理智等

來源

2011-10-17 14:32:36

序列化是好的，但不是我感覺的非常優化的解決方案。如果它更接近於存儲不同版本的差異，則會很有趣。 – linuxeasy

@linuxeasy你會花費更多的週期來試圖找出存儲的內容，而不是僅僅存儲它。 Knuth會做什麼？ –

我們將存儲早期業務對象和當前業務對象之間的差異。我們不會試圖弄清楚要存儲什麼和不存儲什麼，但我們正在尋求開發一個通用框架來自動執行此操作。因此，問題是什麼纔是最有效的通用算法。存儲diff還有幾個優點，例如突出顯示差異。所以，雖然它有點複雜而不是傾銷，但它在節省內存和突出差異方面也有其優勢。 – linuxeasy

之外基本上你應該能夠比較現有的對象和新對象的字段和堅持的差異。

通常會對高度敏感的實體進行跟蹤，以瞭解該特定行/帳戶的更改數量。如果所有表格都完成了，那將是一種矯枉過正的行爲。這些差異可以在與在線表格的相同設計匹配的單獨歷史記錄表中異步保存。

來源

2011-10-20 16:15:11 r0ast3d

equals方法可以接受一個參數併爲此進行比較。 http://en.wikibooks.org/wiki/Java_Programming/Comparing_Objects在持續存在之前，如果我們可以與現有實體進行比較，我們可以將差異另存爲歷史。 – r0ast3d

好的，第一件事，如果你可以指定什麼應該是最好的方式來做到這一點。其次，請考慮複雜的對象，如由子對象組成的對象。例如：Purchase-Order是一個Object，Purchase-Order-Items是子對象。購買訂單直接屬性的差異可以做出。購買訂單項目的差異如何？這些將會有自己的屬性。那裏不會只有1個，但很多購買訂單項目。你認爲哪種數據庫結構最適合使用它？也通過鏈接，我不覺得它是一個非常通用的解決方案。 – linuxeasy

無法將採購訂單項目作爲等值的一部分進行比較以確定更改嗎？我認爲採購訂單項目是採購訂單實體的一部分。子實體也可以實現equals。或者對於更通用的解決方案，簡單的反射實用程序也可以幫助比較字段並再次嘗試遞歸。 – r0ast3d

東西沿着Hibernate Envers線 - 一個實體的審計解決方案，似乎是一個非常適合您的需求。

來源

2011-10-20 16:39:56

我不得不這樣做，在過去類似的措施。

我發現，最簡單的方法，如果從頭開始是在舉行的置換對象的索引對象的數據表中添加一個額外的列。如果價值爲零，那麼我知道這是最新版本。這也意味着對象從未被刪除，儘管我後來添加了允許刪除過去歷史的功能。

有效的指標成爲討論的對象以及任何查詢到DB最新的版本將使用限定WHERE NextVersionIndex=0的版本號。

如果不是從頭開始，這可以通過添加額外的表來存儲這些值被實現爲活動的系統啓動 - 對象指數，上一個版本索引，下一個版本的索引。

來源

2011-10-26 07:35:30 ChrisBD

如何版本動態業務對象/數據？

回答

相關問題