Database design 保存历史数据

我正在编写一个标准的数据库支持的业务应用程序。假设我处理银行账户和“决策”。决策是用户将资金从一个帐户转移到另一个帐户的选择。每个决定都是在特定的日期作出的。一个决策可以有一个或多个“源帐户”，每个“源帐户”将有一个或多个“目标帐户”。我们称之为源帐户，因为钱会离开帐户。。。此外，每个决策和账户都有相关信息，如姓名、余额等

用户希望查看其过去的决策，并且有一个不寻常的业务需求。默认情况下，当决策时间到来时（例如每个月的第一天），他希望将以前的所有决策复制到新的月份。这是因为他很可能会一次又一次地做出相同的决定，但他希望在新的一个月内能够灵活地更改决定的任何参数，而不会影响他之前的几个月

---

作为程序员，当用户开始新的一个月时，我只需在决策表中插入新行，但我会更新Decision.Date。这样，用户可以每月更改每个决策的源帐户列表。有没有一种更优雅的方法可以实现同样的目标，而不必复制所有决策？

你可以用写的方式来代替。只需显示上个月的“决定”，并让用户选择和编辑它们。但是，当它被“保存”时，您将插入一个新行，而不是更新。这使得上个月的“决定”更像是本月的模板，而不是绝对的

如果用户不希望上个月的“决定”发生在这个月，那么在这两者之间的选择可能会对您的行为产生相当大的影响。您正在删除额外的行吗？它们是在没有用户输入的情况下自动生效，还是在创建时停用，等等

另一种选择是版本控制机制。每个“决策”都有一个Id和一个版本（或生效日期）。每个月的决策都有决策ID和决策版本。更新决策的“关键字段”将导致创建新版本。它保存着变化的历史和每个“决定”的血统

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

您的“决策”在会计中被视为交易，当一个交易有多个借方/贷方来源时被细分

我将继续记录帐户事务-这是对开发人员和客户的审计跟踪。但这张表的填写有一个问题，即它的使用范围有限（如果有的话）——最有可能的搜索是在当前月份内，可以追溯到6个月以前。您可能希望根据滚动日期而不是年份变化来归档数据

---

我使用过的大多数会计系统都允许安排对外交易（即：抵押、汽车贷款、医疗、保险）-根据以前的信息插入新记录，并相应地更新日期是无害的。

COW在我看来比推出数据更有意义，考虑到用户很少改变决策。