2009-09-27 262 views
0

我正在編寫一個標準的數據庫支持的業務應用程序。假設我使用銀行賬戶以及「決定」。決定是用戶從一個賬戶向另一個賬戶轉移資金的選擇。每個決定都是在特定的日期進行的。決定可以有一個或多個「源帳戶」,每個「源帳戶」將有一個或多個「目標帳戶」。我們稱他們爲源帳戶,因爲這筆錢將離開帳戶...而且每一個決策和賬戶有相關的信息,如姓名,平衡等保存歷史數據

用戶想查看自己過去的決定,並有着不同尋常的業務需求。默認情況下,當決定時間到了(例如每個月的第一個)時,他希望所有以前的決定都被複制到新的月份。這是因爲他很可能會一遍又一遍地做出同樣的決定,但他希望在不影響他以前的幾個月的情況下靈活地改變任何一個月的決定參數。

作爲一個程序員,當用戶啓動一個新的一個月,我只是在我的決策表中插入新行,但我更新Decision.Date。這樣,用戶可以每個月更改每個決策的源帳戶列表。有沒有更好的方法來實現同樣的事情,而不需要複製所有的決定?

回答

0

您可以改寫寫上的副本。只顯示上個月的「決定」,並讓用戶選擇並編輯它們。但是,當它「被保存」時,你會插入一個新行而不是更新。這使得上個月的「決定」更多地成爲本月的模板,而不是絕對的。

如果用戶不想需要本月的上個月「決定」,那麼兩者之間的選擇可能會相當大地影響您的工作。你是否刪除額外的行?難道他們會自動生效,沒有用戶輸入的,或者在創建時停用,等

另一種選擇可能是一個版本控制機制。每個「決定」都有一個Id和一個版本(或生效日期)。每個月的決定都有DecisionId和DecisionVersion。更新決策的「關鍵字段」會導致創建新版本。這保留了每個「決定」的變化和譜系歷史。

在像「自動儲蓄計劃」這樣的場景中,版本控制對我來說是有意義的。您可以創建一個名爲「自動儲蓄計劃」的「決策」,並且您可以更改金額,來源帳戶等 - 但它們仍然是「自動儲蓄計劃」決策的一部分。

+0

考慮到用戶很少改變決策,COW比滾動數據更有意義。 – 2009-09-27 22:52:47

1

你的「決定」被視爲交易的會計,分爲T accounts當一個事務有多個借記/貸記來源。

我會繼續記錄帳戶交易 - 這是開發者和客戶端的審計跟蹤。但是,這張表填補了有限的空間(如果有的話) - 最有可能的搜索將會在本月內進行,可能會延續到6個月。您希望根據滾動日期歸檔數據,而不是在年份變更時歸檔。

我與之合作過的大多數會計系統都可以安排即期交易(IE:按揭,汽車貸款,醫療,保險) - 根據以前的信息插入新記錄並相應地更新日期。