2012-04-11 43 views
2

我試圖通過添加版本控制來爲現有系統帶來理智。麻煩的是系統不能很好地轉換成像佈局這樣的文件系統。經過幾次思考實驗後,我有一個基本的方法來處理這個問題,但在我開始允許使用這個混亂之前,我想通過集體來運行它。爲對象和鏈接創建版本控制系統

該系統由鍵入的對象和鏈接組成。 對象與鏈接錶鏈接在一起形成有意義的關係。 鏈接也是類型化的對象,可以有自己的屬性。

用戶可以在任何級別到達對象的視圖,然後在鏈接之後上下走動以查看關係。

大多數對象都有數百個指向其他對象的鏈接。 並非所有的對象或鏈接都將受版本控制,因爲有些可以被認爲是靜態的。 允許版本控制鏈接到非版本控制對象。

對象的更改以包含層次結構的整個佈局的批處理方式到達,它們本身沒有或沒有最小用戶註釋或版本信息。 因此,通過比較新對象與前一個對象來檢測更改。鏈接更改也以這種方式檢測到。對象可以添加到一個版本中,在下一個版本中刪除,並在下一個版本中再次添加。大多數物體都有足夠的獨特信息來檢測這個物體的確是同一個物體,它們是存在和不存在的物體。

不改變的對象和鏈接不應該爲單個對象創建新版本,但批量更新產生的整體內容仍應作爲一個組進行標識。

95%的用戶只會對最新版本的對象/關係感興趣,但我需要能夠顯示其餘5%的先前承諾的對象/關係。

我最初的想法是爲這批更改實現一個整體版本uid,並將其與該迭代的所有當前對象/鏈接關聯。剩下的要抓緊抓住。如果你做到了這一點,謝謝。思考?

回答

2

這聽起來像你正在描述(關係)數據庫。您最喜愛的搜索引擎會爲您提供一些關於如何進行數據庫版本控制的鏈接。

兩個examples對於SQL

+0

非常釘它。我沒有把2 + 2放在一起。我通過使用提交日期作爲超出對象已有UID的版本標識符來簡化此操作。 – 2012-05-10 14:21:19