保留历史数据
我正在编写一个标准的数据库支持的业务应用程序。假设我处理银行账户和“决策”。决定是用户将资金从一个帐户转移到另一个帐户的选择。每个决定都是在特定日期做出的。一项决策可以有一个或多个“源帐户”，每个“源帐户”将有一个或多个“目标帐户”。我们称它们为源帐户，因为钱会离开该帐户...而且每个决策和帐户都有相关信息，例如姓名、余额等。
用户希望查看他过去的决策，并且有不寻常的业务需求。默认情况下，当决策时间到来时（例如每个月的第一天），他希望将所有以前的决策复制到新的月份。这是因为他很可能一遍又一遍地做出相同的决定，但他希望能够灵活地更改新月份决策的任何参数，而不会影响他之前的几个月。
作为一名程序员，当用户开始新的一个月时，我只需在决策表中插入新行，但会更新 Decision.Date。这样，用户可以每月更改每个决策的源帐户列表。有没有一种更优雅的方式来实现同样的事情，而无需复制所有决策？
I am writing a standard database-backed business application. Assume that I work with bank accounts as well as "Decisions". A decision is a choice the user takes of moving money from one account to another. Each decision is taken at a particular date. A decision can have one or more "source accounts", and each "source account" will have one or more "destination accounts". We call them source accounts because money will leave the account... Also each decision and account have related information such as names, balance, etc.
The user would like to view his past decisions, and has an unusual business requirement. By default, when decision time comes (for example the first of each month), he would like all previous decisions to be copied over to the new month. This is because he's very likely to take the same decision over and over,but he would like the flexibility of changing any parameter of a decision for a new month, without impacting his previous months.
As a programmer, when the user starts a new month, I simply insert new rows in my Decision table, but I update Decision.Date. That way, the user can change the list of source accounts for each decision, each month. Is there a more elegant way of achieving the same thing, without copying over all decisions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的“决策”被视为会计中的交易，当交易有多个借方时，会细分为T 账户 /信用来源。
我将继续记录帐户交易 - 这是开发人员和客户的审计跟踪。但有人担心此表的填充量有限（如果有用途的话）——最有可能的搜索将在当月内进行，可追溯到约 6 个月。您希望根据滚动日期而不是年份更改来存档数据。
我使用过的大多数会计系统都允许安排传出交易（即：抵押贷款、汽车贷款、医疗、保险）——根据以前的信息插入新记录并相应地更新日期并没有什么坏处。
Your "Decisions" are considered transactions in Accounting, subdivided into T accounts when a transaction has multiple debit/credit sources.
I would continue to log account transactions - it's an audit trail for both the developer and the client. But there is a concern with this table filling up for limited (if any use) - the most likely search is going to be within the current month, going back ~6 months. You'd want to archive the data based on a rolling date rather then at the year change.
Most accounting systems I've worked with allow for the ability to schedule outgoing transactions (IE: mortgage, car loan, medical, insurance) - there's no harm in inserting new records based on the previous information, updating the date accordingly.
您可以改为在写入时进行复制。只需显示上个月的“决策”，然后让用户选择并编辑它们。但是，当它“保存”时，您将插入一个新行而不是更新。这使得上个月的“决定”更多地是本月的模板，而不是绝对的。
如果用户不想要本月的上个月的“决定”，那么两者之间的选择可能会对您的操作产生很大的影响。您要删除多余的行吗？它们是在没有用户输入的情况下自动生效，还是在创建时停用，等等。
另一个选项可能是版本控制机制。每个“决定”都有一个 ID 和一个版本（或生效日期）。每个月的决策都有 DecisionId 和 DecisionVersion。更新决策的“关键字段”会导致创建新版本。这保留了变化的历史和每个“决定”的血统。
在“自动储蓄计划”这样的场景中，版本控制对我来说很有意义。您将创建一个名为“自动储蓄计划”的“决策”，并且您可以更改金额、来源帐户等 - 但它们仍然是“自动储蓄计划”决策的一部分。
You could do a copy on write instead. Just show last month's "Decisions", and let the user pick and edit them. But, when it's "saved", you'd insert a new row instead of updating. That makes last month's "Decisions" more of a template for this months rather than an absolute.
The choice between the two would probably weigh pretty heavily on what you do if the user doesn't want last month's "Decisions" for this month. Are you deleting the extra rows? Do they automatically take effect with no user input, or are they deactivated when created, etc.
Another option could be a versioning mechanism. Each "Decision" gets an Id and a version (or Effective Date). Each month's Decision has both the DecisionId and the DecisionVersion. Updating "key fields" of the Decision results in a new version being created. That keeps a history of changes and a lineage for each "Decision".
Versioning would make sense to me in a scenario like "Automatic Savings Plan". You'd create a "Decision" with a name "Automatic Savings Plan", and you'd be able to change the amount, source accounts, etc. - but they'd still be part of the "Automatic Savings Plan" Decision.