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

前端之家收集整理的这篇文章主要介绍了数据库 – 衍生账户余额与简单银行帐户的存储帐户余额?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
所以,就像我们正常的银行帐户,我们有很多交易导致资金流入或流出.总是可以通过简单地总结交易值来获得账户余额.在这种情况下会更好,将更新的帐户余额存储在数据库中或在需要时重新计算?

每个帐户的预期交易量:< 5日 帐户余额的预期检索:每当交易发生时,平均每天一次. 你会如何建议对此做出决定?
非常感谢!

解决方法

Preface

This is the age of subjective “truth”,and objective truth,which flows from an Authority,and which has been in place for four thousand years,is something that we are now being programmed to rebel against.

I have worked on accounting systems for 34 years,and banking systems for 24 years. There is an objective truth: Audit requirements. Additionally,when dealing with public funds,there is Legislature that must be complied with.

You don’t have to implement the full accounting requirement,you can implement just the parts that you need.

Conversely,it would be ill-advised to implement something other than the standard accounting requirement (the parts thereof) because that guarantees that when the number of bugs or the load exceeds some threshold,or the system expands,you will have to re-implement. A cost that can,and therefore should,be avoided.

It also needs to be stated: do not hire an unqualified,un-accredited (by an Authority) “auditor”. That is (a) an act of rebellion against Authority,and (b) there will be consequences,the same as if you hired an unqualified developer. It might be worse,if the higher authority such as the Tax Office fines you.

Therefore,be aware of the hierarchy of Authorities,and comply with the highest one. That ensures a peaceful life. That ensures that automatically,without additional effort,you comply with any lower authority. If you fail to do that,ie. comply with some lower Authority,but rebel against some higher one,the higher Authority will get you in the end.

方法

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

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

考虑

一,考虑.

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

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

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

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

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

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

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

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

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

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

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

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

履行

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

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

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

>再次,如果您的表是Relational,AccountTransaction的主键将是(AccountCode,TransactionDateTime),它将以毫秒的速度检索事务.
>而对于记录归档系统,“主键”将为(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浏览器.打印;评论;更改交易;重印;重新审查,直到你开心.在任何情况下都没有意义.这就是为什么在较不原始的国家,法院不接受任何旧的印刷品,他们只接受公开的数字,例如.已经受审核要求(参见上述方法)的银行对账单,无法回调或更改并重印.

猜你在找的MsSQL相关文章