数据库 – 衍生账户余额与简单银行帐户的存储帐户余额？

方法

这种原始国家的标准会计方法是这样的. “最佳实践”,如果你愿意,在别人身上.

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

考虑

一,考虑.

>不要重复数据.如果可以导出当前的余额(这里很简单),不要用汇总列复制.这样一列是数据的重复.它违反规范化规则.此外,它创建一个更新异常,否则不存在.
>如果您使用摘要列,每当更新事务(如更改时,不会像插入新事务时)更新,则汇总列值将过时,因此必须始终更新.这是更新异常的结果.这消除了拥有它的价值.
>外部刊物.如果余额发布,如每月银行对账单,这些文件通常具有法律限制和影响,因此公布的CurrentBalance值在出版后不得更改.

>在出版日期之后,在数据库中发布的外部图形的任何变化都是不诚实行为,欺诈等的证据.

>这种行为,试图改变已发表的历史,是新手的标志.新手和精神病人会坚持历史可以改变.但是,每个人都应该知道,对法律的无知并不构成有效的辩护.

>您不希望您的银行在2015年4月将您在“银行对账单”中发布的“当期余额”更改为2014年12月.
>这个数字必须被看作是一个审计人物,出版和不变.

>任何必要的更正或调整均作为当月的新交易作出,即使适用于上个月.这是因为适用月份已关闭并发布,因为在发生事件之后不能更改历史记录,并且已被记录.唯一有效的一个月是现在的一个月.

>在不那么原始的国家,如果发生错误,有兴趣的系统等,并且具有历史性的影响(例如,您在2015年4月发现,安全性计算的利息是不正确的,因为2014年12月),今天计算更正的利息支付/扣除的价值,错误的天数,并将该金额作为当月的交易插入.再次,唯一有效的一个月是现在的一个月.

当然,安全的利率也要纠正,所以错误并不重复.
>如果您的银行计算您的储蓄(生息)账户的利息发生错误,并且您已更正,则您将获得一笔存款,即当前月份的整个调整值.那是当月的交易.

银行没有：改变历史;每个历史月份都有利益;回顾历史悠久的“银行报表”;重新发布历史悠久的“银行报表”.不,除了Idi Amin型国家.
>相同的原则适用于库存控制系统.它保持理智

>所有真正的会计系统(即审查机构在适用国家认可的系统,而不是米奇鼠标“包”)都使用双入门系统进行交易,正是因为它阻止了一大堆错误,其中最重要的是资金不会“迷失”.这需要一个简单的总帐.

>你可能不需要这个,所以我没有在这里描述,但是请记住,如果钱“丢失”,因为这将是你必须实现的,而不是一些帮助解决方案;不是另一个未经认证的“包”.

>影响性能的主要问题超出了此问题的范围,它们在您是否实施真正的关系数据库(sql数据库容器中的记录文件系统,以ID为代表)的领域.

>使用真正的关系密钥等将保持高性能,不管表的数量.
>相反,RFS会表现不佳,他们根本无法执行.在“RFS”中使用的“规模”是一种欺诈性术语：它隐藏了原因,并寻求解决一切,除了原因之外.

履行

>对于每个帐户,在AccountStatement表中将显示一个ClosingBalance(每个帐户每月一行),以及StatementDate和其他Statement详细信息.

>这不是重复的,因为它是要求审计和理智的目的.

对于库存,一个QuantityOnHand列,在PartAudit表(每个部分每个月一行)
>它有一个额外的值,因为它限制了当前月份需要查询的事务行的范围

>再次,如果您的表是Relational,Accounttransaction的主键将是(AccountCode,transactiondatetiR_8_11845@E),它将以毫秒的速度检索事务.
>而对于记录归档系统,“主键”将为(transactionID),并且您将通过transactionDate检索当前月份,该对象可能被正确地索引,也可能不会被索引,并且所需的行将被分散在该文件中.在任何情况下,远远小于Clusteredindex速度,并且检索到的行数量很多,可以是tablecan.

>交易表保持简单(银行账户的真实世界概念交易很简单).它具有单个“正数”列.
>对于每个帐户,CurrentBalance是：

>上个月的Statement.ClosingBalance

(对于库存,PartAudit.QuantityOnHand)
>加上当前月份的transaction.amounts的总和,其中transactionType表示存款

(对于库存,transaction.QuantityAffected)
>减去当前月份中transaction.amounts的总和,其中transactionType表示撤销

>在本方法中,本月的交易仅处于通量状态,因此必须得出.所有前几个月都会公布和关闭,因此必须使用审计数字.
>可以清除“交易”表中的较旧行.十年以上的公款,其他五年,爱好俱乐部系统一年.
>当然,与会计系统相关的任何代码都使用正版的OLTP标准和真正的sql ACID交易至关重要.
>此设计包含所有范围级别的性能考虑因素(如果不明显,请咨询扩展).缩放是一个非问题,现在扩展问题是诚实地在数据库之外.

纠正建议

这些项目需要说明,因为在“答案”中提供了不正确的建议(当然,由民众参与,并且互联网充满错误的建议)(业余爱好者喜欢发表主观的“真理” “)：

显然,有些人不明白我已经在技术上给出了一个方法.因此,它不是特定国家的特定应用程序的伪代码.该方法适用于有能力的开发人员,对于那些需要领先的人来说,这种方法不够详细.

>他们也不明白,一个月的截止时间就是一个例子：如果你的税务局的截止是季度,那么一定要用一个季度的截止;如果您唯一的法定要求是年度使用年度.
>即使您的截止是季度为外部或合规目的,该公司也许可以选择每月截止,以内部审计和理智目的(即将流量状态的时间长度保持在最小值) ).

例如.在澳大利亚,税务局对企业的截止是季度,但大公司每月将其库存控制权关闭(这样可以节省长时间追赶错误).

例如.银行每月都有法定合规要求,因此他们对数字进行内部审计,并每月关闭账簿.
>在原始国家和流氓国家,由于明显的恶意目的,银行将其通货期保持在最大值.其中一些只能每年提交合规报告.这就是为什么澳大利亚的银行不会失败的原因之一.

>在“交易”表中,不要在“金额”列中使用负数/正数.钱总是有一个积极的价值,没有这样的东西,如负二十美元(或你欠我五十美元,然后说出双重否定意味着别的东西).
>运动方向,或您将要对资金做些什么,是一个单独的离散的事实(对于transaction.amount).这需要一个单独的列(一个数据中的两个事实打破规范化规则,其结果是将复杂性引入到代码中).

>实现一个transactionType列,它是(D,W)作为存款/提取作为起点.随着系统的发展,只需添加(A,R,W,M)进行调整,退款,ATM_Withdrawal,Management_Fee等.
>不需要更改代码.

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

显然,我不会反对法庭的要求.问题是原始编码器将其转换为：哦,我们必须实现一个transaction.CurrentBalance列.他们不明白：

>在报告上打印列的要求不是在数据库中存储值的规定
>任何类型的运行总计是派生值,并且它很容易编码(发布问题,如果这不容易).只需在报表中实现所需的代码即可.
实施运行总计例如. transaction.CurrentBalance作为列导致可怕的问题：

>引入了一个重复的列,因为它是可推导的.打破规范化.推出更新异常.
>更新异常：每当事务历史插入或transaction.amount更改时,必须重新计算和更新从该日期到当前的所有transaction.CurrentBalances.

>在上述情况下,提交法庭使用的报告现在已经过时了(在打印的时刻,每个在线数据的报告已经过时). IE浏览器.打印;评论;更改交易;重印;重新审查,直到你开心.在任何情况下都没有意义.这就是为什么在较不原始的国家,法院不接受任何旧的印刷品,他们只接受公开的数字,例如.已经受审核要求(参见上述方法)的银行对账单,无法回调或更改并重印.