2009-09-27 131 views
0

我正在编写一个标准的数据库支持的业务应用程序。假设我使用银行账户以及“决定”。决定是用户从一个账户向另一个账户转移资金的选择。每个决定都是在特定的日期进行的。决定可以有一个或多个“源帐户”,每个“源帐户”将有一个或多个“目标帐户”。我们称他们为源帐户,因为这笔钱将离开帐户...而且每一个决策和账户有相关的信息,如姓名,平衡等保存历史数据

用户想查看自己过去的决定,并有着不同寻常的业务需求。默认情况下,当决定时间到了(例如每个月的第一个)时,他希望所有以前的决定都被复制到新的月份。这是因为他很可能会一遍又一遍地做出同样的决定,但他希望在不影响他以前的几个月的情况下灵活地改变任何一个月的决定参数。

作为一个程序员,当用户启动一个新的一个月,我只是在我的决策表中插入新行,但我更新Decision.Date。这样,用户可以每个月更改每个决策的源帐户列表。有没有更好的方法来实现同样的事情,而不需要复制所有的决定?

回答

0

您可以改写写上的副本。只显示上个月的“决定”,并让用户选择并编辑它们。但是,当它“被保存”时,你会插入一个新行而不是更新。这使得上个月的“决定”更多地成为本月的模板,而不是绝对的。

如果用户不想需要本月的上个月“决定”,那么两者之间的选择可能会相当大地影响您的工作。你是否删除额外的行?难道他们会自动生效,没有用户输入的,或者在创建时停用,等

另一种选择可能是一个版本控制机制。每个“决定”都有一个Id和一个版本(或生效日期)。每个月的决定都有DecisionId和DecisionVersion。更新决策的“关键字段”会导致创建新版本。这保留了每个“决定”的变化和谱系历史。

在像“自动储蓄计划”这样的场景中,版本控制对我来说是有意义的。您可以创建一个名为“自动储蓄计划”的“决策”,并且您可以更改金额,来源帐户等 - 但它们仍然是“自动储蓄计划”决策的一部分。

+0

考虑到用户很少改变决策,COW比滚动数据更有意义。 – 2009-09-27 22:52:47

1

你的“决定”被视为交易的会计,分为T accounts当一个事务有多个借记/贷记来源。

我会继续记录帐户交易 - 这是开发者和客户端的审计跟踪。但是,这张表填补了有限的空间(如果有的话) - 最有可能的搜索将会在本月内进行,可能会延续到6个月。您希望根据滚动日期归档数据,而不是在年份变更时归档。

我与之合作过的大多数会计系统都可以安排即期交易(IE:按揭,汽车贷款,医疗,保险) - 根据以前的信息插入新记录并相应地更新日期。