衍生帐户余额与存储帐户余额的简单银行帐户？

Question

因此,它就像我们的正常银行账户,我们有很多交易导致资金流入或流出.总是可以通过简单地总结交易价值来得出账户余额.在这种情况下,将更新的帐户余额存储在数据库中或在需要时重新计算时会更好？

每个帐户的预期交易量:每天<5

预期的帐户余额检索:每当交易发生时,平均每天一次.

您如何建议对此做出决定？非常感谢!

Answer 1

前言

这是一个主观"真理"的时代,客观真理从一个管理局流出,已经存在了四千年,这是我们现在被编程反叛的东西.

我从事会计系统工作34年,银行系统工作24年.有一个客观事实:审计要求.此外,在处理公共资金时,必须遵守立法机关.

您无需实施完整的会计要求,只需实施所需的部件即可.

相反,实施标准会计要求(其中的部分)之外的其他内容是不明智的,因为这可以保证当错误或负载数量超过某个阈值或系统扩展时,您将不得不重新实施.可以而且应该避免的成本.

还需要说明的是:不要雇用不合格的,未经认证的(由管理局)"审计员".这是(a)对管理局的反叛行为,(b)会产生后果,就像你雇用一名不合格的开发商一样.如果税务局等上级机构对您进行罚款,情况可能会更糟.

因此,请注意权限的层次结构,并遵守最高权限.这确保了和平的生活.这确保您可以自动地,无需额外的努力,遵守任何较低的权限.如果你没有这样做,即.遵守一些较低的权威,但反对一些更高的权威,更高的权威将最终得到你.

方法

不太原始的国家的标准会计方法就是这样.如果你愿意的话,"最佳实践",在其他人中.

此方法适用于具有类似操作的任何系统; 需要; 历史月度数据与当前月份要求,如库存控制等.

考虑

首先,考虑因素.

1. 永远不要重复数据 如果可以导出当前余额(这里很简单),请不要使用摘要列复制它.这样的列是数据的重复.它打破了规范化规则.此外,它会创建一个更新异常,否则不存在.

2. 如果使用摘要列,则每当更新事务时(如更改时,而不是插入新事务时),摘要列值将变得过时,因此必须始终更新它.这是Update Anomaly的结果.这消除了拥有它的价值.

3. 外部出版物.如果余额发布,如每月的银行对账单,这些文件通常具有法律限制和含义,因此公布的CurrentBalance值在发布后不得更改.

   • 在发布日期之后,在数据库中,对外部发布的数字进行的任何更改都是不诚实行为,欺诈等的证据.

     • 这种试图改变出版历史的行为是新手的标志.新手和精神病患者会坚持认为历史可以改变.但正如每个人都应该知道的那样,对法律的无知并不构成有效的辩护.

   • 您不希望您的银行在2015年4月将您在银行对帐单中发布的当前余额更改为2014年12月.

   • 该数字必须被视为审计数字,已公布且不可更改.

4. 必要的任何更正或调整都将作为当前月份的新交易进行,即使它适用于上个月.这是因为适用的月份已关闭并发布,因为在发生历史记录并且已记录之后,不能更改历史记录.唯一有效的月份是当前的月份.

   • 对于生息系统等,在不那么原始的国家,当发现错误时,它具有历史性的影响(例如,你在2015年4月发现,对证券计算的利息不正确,自12月以来对于错误的天数,今天计算更正的利息支付/扣除的价值,并将该金额作为当前月份的交易插入.同样,唯一有效的月份是当前的月份.

     当然,安全性的利率也必须得到纠正,因此错误不会重复.

   • 如果您发现银行计算您的储蓄(计息)账户的利息时出现错误,并且您已将其更正,那么您将在当月获得一笔存款,构成整个调整值.这是本月的交易.

     银行没有:改变历史; 申请每个历史月份的利息; 回顾历史性的银行对账单; 重新发布历史性的银行对账单.不可以.也许在Idi Amin类型的国家.

   • 同样的原则适用于库存控制系统.它保持理智.

5. 所有真实的会计系统(即在适用的国家/地区通过审计机构认证的系统,而不是大量的米老鼠"包装")使用双重进入系统进行交易,正是因为它可以防止大量错误,最重要的是,资金不会"丢失".这需要一个简单的总帐.

   • 你可能不需要那个,因此我不是在这里描述它,但要记住它,以防钱"缺失",因为这是你必须实现的,而不是一些创可贴解决方案; 还没有另一个未经认可的"包裹".

6. 影响性能的主要问题超出了本问题的范围,它们是否是您实现真正的关系数据库(SQL数据库容器中的记录归档系统,以ID为代表).

   • 无论表的填充程度如何,使用真正的关系密钥等都将保持高性能.

   • 相反,RFS表现不佳,他们根本无法执行.在RFS的背景下使用"缩放"是一个欺诈性的术语:它隐藏了原因并试图解决除原因之外的所有事情.

履行

1. 对于每个帐户,AccountStatement表中都会有一个ClosingBalance(每个帐户每月一行),以及StatementDate和其他Statement详细信息.

   • 这不是重复的,因为它需要审计和健全的目的.

     对于Inventory,一个QuantityOnHand列,在PartAudit表中(每个部件每月一行)

   • 它有一个额外的值,因为它限制了当前月份所需查询的事务行的范围

     • 同样,如果您的表是Relational,则AccountTransaction的主键将是(AccountCode,TransactionDateTime),它将以毫秒速度检索事务.

     • 而对于记录归档系统,"主键"将是(TransactionID),并且您将通过TransactionDate检索当前月份,其可能正确索引或未正确索引,并且所需的行将分布在整个文件中.在任何情况下,远远低于ClusteredIndex速度,并且检索到的行很多,表扫描.

2. 交易表仍然很简单(银行账户交易的现实概念很简单).它有一个正数量列.

3. 对于每个帐户,CurrentBalance是:

   • 上个月的Statement.ClosingBalance

     (对于库存,PartAudit.QuantityOnHand)

   • 加上当前月份的Transaction.Amounts的总和,其中TransactionType表示存款

     (对于库存,Transaction.QuantityAffected)

   • 减去当前月份中Transaction.Amounts的总和,其中TransactionType表示提款

4. 在此方法中,仅当前月份的交易处于不稳定状态,因此必须导出它们.所有前几个月都已公布和结束,因此必须使用审计数据.

5. 可以清除Transaction表中的旧行.公共资金超过十年,否则为五年,业余爱好俱乐部系统为一年.

6. 当然,任何与会计系统相关的代码都必须使用正版的OLTP标准和真正的SQL ACID交易.

7. 此设计包含所有范围级别的性能考虑因素(如果这不明显,请请求扩展).扩展是一个非问题,现在扩展问题诚实地在数据库之外.

纠正建议

这些项目之所以需要说明,只是因为在SO Answers中提供了错误的建议(当然是民主上的民众投票),互联网上充满了错误的建议(业余爱好者喜欢发表他们的主观"真相") "):

1. 显然,有些人不明白我在技术方面给出了一个方法.因此,它不是特定国家/地区中特定应用程序的伪代码.该方法适用于有能力的开发人员,对于那些需要牵手的人来说,它并不够详细.

   • 他们也不明白一个月的截止期是一个例子:如果税务局的截止时间是季度,那么无论如何都要使用季度截止日期; 如果您拥有的唯一法律要求是年度,则使用年度.

   • 即使您的外部或合规目的是季度截止,公司也可以选择每月截止,用于内部审计和健全目的(即保持通量状态周期的长度最小) .

     例如.在澳大利亚,税务局对企业的停产季度,但较大的公司每月停止库存控制(这节省了长期追逐错误).

     例如.银行每月都有法律合规要求,因此他们会对数据进行内部审计,并每月关闭账簿.

   • 在原始国家和流氓国家,由于明显的邪恶目的,银行将其流通状态时期保持在最大值.其中一些人每年只会制作合规报告.这就是为什么澳大利亚的银行不会失败的原因之一.

2. 在"事务"表中,不要在"金额"列中使用负数/正数.金钱总是有正值,没有负二十美元(或者你欠我五十美元,然后确定双重否定意味着别的东西).

3. 移动方向,或者你要对资金做什么,是一个独立的,离散的事实(对于Transaction.Amount).这需要一个单独的列(一个数据中的两个事实打破规范化规则,结​​果是它在代码中引入了复杂性).

   • 实现TransactionType列,即存款/取款的(D,W)作为起点.随着系统的增长,只需​​添加(A,R,w,M)进行调整,退款,ATM_Withdrawal,Management_Fee等.

   • 无需更改代码.

4. 在一些原始国家,诉讼要求规定,在列出交易的任何报告中,必须在每一行显示一个运行总计.(注意,这不是审计要求,因为这些要求比法院要求更优越[上述方法];审计师比律师更愚蠢;等等)

   显然,我不会与法院要求争论.问题是原始编码器将其转换为:哦,我们必须实现 Transaction.CurrentBalance 列.他们不明白:

   • 在报表上打印列的要求不是在数据库中存储值的指令

   • 任何类型的运行总计都是派生值,并且很容易编码(如果对您来说不容易发布问题).只需在报告中实现所需的代码即可.

   • 实施运行总计,例如.Transaction.CurrentBalance作为列导致可怕的问题:

     • 引入了重复的列,因为它是可派生的.打破规范化.介绍更新异常.

     • 更新异常:每当历史插入事务或更改Transaction.Amount 时,必须重新计算和更新从该日期到现在的所有Transaction.CurrentBalances .

   • 在上述情况下,提交法院使用的报告现已过时(每一份在线数据报告在印刷时都已过时).IE浏览器.打印; 评论; 改变交易; 重印; 重新审视,直到你开心.无论如何都没有意义.

   • 这就是为什么在不太原始的国家,法院不接受任何旧的印刷纸,他们只接受公布的数字,例如.银行对账单已经满足审计要求(参见上述方法),无法召回或更改并重新打印.