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

Question

因此，就像我们的普通银行帐户一样，我们有很多交易导致资金流入或流出。始终可以通过简单地汇总交易值来得出帐户余额。在这种情况下，将更新后的帐户余额存储在数据库中或在需要时重新计算该余额会更好吗？

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

预期取回帐户余额:每发生一次交易，平均一天一次。

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

Answer 1

Preface

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 "auditor". There will be consequences, the same as if you hired an unqualified developer. It might be worse, if the Tax Office fines you.

方法

在不太原始的国家中，标准会计方法就是这样。如果您愿意的话，这是“最佳实践”。

此方法适用于任何具有类似操作的系统；需求；历史月度数据与当月需求(例如库存控制等)

考虑

首先，注意事项。

从不重复数据。
如果可以得出“当前余额”(在这里很简单)，则不要在“摘要”列中重复它。这样的列是数据的重复。它违反了规范化规则。此外，它会创建一个更新异常，否则将不存在。

如果您确实使用汇总列，则每当更新事务时(更改时，而不是插入新事务时)，汇总列值将过时，因此无论如何都必须始终对其进行更新。那是更新异常的结果。这消除了拥有它的值(value)。

外部出版物。
分隔点。如果以每月银行对帐单的形式发布余额，则此类文件通常具有法律限制和含义，因此发布后的“当前余额”值不得更改。

在发布日期之后，数据库中对外部发布的图形的任何更改，都是不诚实行为，欺诈等的证据。

这种尝试改变已发布历史的行为是新手的特点。新手和精神病患者都会坚持认为历史可以改变。但众所周知，法律的无知并不构成有效的辩护。

您不希望您的银行在2015年4月更改他们在2014年12月发给您的银行对帐单中显示的当前余额。

该图必须被视为审计图，已发布且不可更改。

要更正过去所犯的错误，即当前要纠正的错误，必须进行必要的更正或调整，将其作为当月的新事务处理(即使它适用于某些上个月或持续时间)。

这是因为适用月份已关闭；已审核；并发布，因为在发生并记录后就无法更改历史。唯一的有效月是当前月份。

对于不太原始的国家中的计息系统等，当发现错误并具有历史性影响时(例如，您在2015年4月发现，以证券计算的利息是不正确的，因为2014年12月)，则今天针对错误的天数计算已校正的利息支付/扣除额的值，并将该金额作为当月的交易插入。同样，唯一有效的月份是当前月份。

当然，还必须更正证券的利率，以使该错误不再发生。

如果在银行的储蓄(计息)帐户的利息计算中发现错误，并且对其进行了更正，您将在当月获得一笔存款，该笔存款构成了整个调整值。那是当月的交易。

银行没有:更改历史记录；为每个历史月份申请利息；回顾历史悠久的银行对账单；重新发布历史悠久的银行对帐单。不可以。除了第三世界国家。

相同的原则适用于库存控制系统。它保持理智。

所有真实的会计系统(即适用国家/地区的审计机构认可的会计系统，而不是比比皆是的米老鼠“包装”)都使用双重输入系统进行交易，这恰恰是因为它可以防止大量错误，其中最重要的是，资金不会“丢失”。这需要总帐和重复输入会计。

您没有要求，您不需要，因此在此不做描述。但是要记住，以防万一钱“丢失”了，因为那是您将要实现的，而不是一些创可贴解决方案。还没有另一个未经认可的“程序包”。

This Answer services the Question that is asked, which is not Double-Entry Accounting.
For a full treatment of that subject (detailed data model; examples of accounting Transactions; rows affected; and SQL code examples), refer to this Q&A:
Relational Data Model for Double-Entry Accounting.

影响性能的主要问题不在此问题的范围内，它们涉及的是您是否实现真正的关系数据库(例如，1960年代的Record Filing System，其特征是Record IDs，已部署在SQL数据库中)方便的容器)。

使用真正的关系键等将保持高性能，而不管表的填充情况如何。

相反，RFS的性能很差，根本无法执行。在RFS上下文中使用“比例”是一个欺诈性的术语:它隐藏了原因并试图解决除原因之外的所有问题。最重要的是，这样的系统没有关系完整性。关系力量；或关系系统的关系速度。

实作

关系数据模型•帐户余额

关系数据模型•库存

符号

我所有的数据模型都以表示IDEF1X ，这是自1993年以来建立关系数据库建模的标准。

我的 IDEF1X Introduction 对于关系模型或其建模方法的新手来说是必读的。请注意，IDEF1X模型具有丰富的细节和精度，可以显示所有必需的细节，而本地模型则远远不止这些。这意味着必须理解该符号。

内容

对于每个帐户，在ClosingBalance表(每月每个AccountStatement一行)中将有一个AccountNo，以及对帐单日期(通常是每月的第一天)和其他对帐单详细信息。

这不是重复的，因为出于审计和理智的目的需要它。

对于库存，它是QtyOnHand表中的PartAudit列(每个PartCode每月一行)

它具有附加值，因为它限制了需要查询的事务行范围到当月的

再次，如果您的表是Relational，AccountTransaction的主键将是(AccountNo，Transaction DateTime)，它将以毫秒的速度检索事务。

对于记录归档系统，“主键”将是TransactionID，并且您将通过“交易日期”来检索当月，该日期可能正确或可能没有正确索引，并且所需的行将散布在整个文件中。在任何情况下，其速度都远低于ClusteredIndex的速度，并且由于传播的原因，它将导致表扫描。

AccountTransaction表保持简单(银行帐户“交易”的实际概念很简单)。它具有单个正Amount列。

对于每个Account，CurrentBalance为:

上个月的AccountStatement.ClosingBalance，为方便起见，日期为下个月的第一天

(对于库存，PartAudit.QtyOnHand)

加上当月AccountTransaction.Amounts的总和，其中TransactionType表示存款

(对于 list ，PartMovement.Quantity)

减去当月AccountTransaction.Amounts的总和，其中`MovementType表示提款。

在此方法中，仅当月的AccountTransactions处于不断变化的状态，因此必须将派生为。之前的所有月份均已发布并关闭，因此必须使用审计图。

可以清除AccountTransaction表中的旧行。超过10年的公共(public)资金年龄，否则为5年，对于业余俱乐部系统则为1年。

当然，与会计系统相关的任何代码都必须使用真正的OLTP标准和真正的SQL ACID Transactions。

此设计结合了所有范围级别的性能考虑因素(如果不明显，请提出扩展要求)。在数据库内部进行扩展不是问题，实际上保留的任何扩展问题都在数据库外部。

纠正建议

只需说明这些内容，是因为许多SO解答中都提供了错误的建议(当然，民主地受到了群众的投票)，并且互联网上充斥着错误的建议(业余爱好者喜欢发布主观的“事实”):

显然，有些人不明白我在技术上给出了一种方法来针对清晰的数据模型进行操作。因此，它不是特定国家/地区中特定应用程序的伪代码。该方法适用于有能力的开发人员，对于需要手工指导的人员而言，方法还不够详细。

他们还不了解一个月的截止日期是示例:如果您为税务局目的的截止日期是每季度一次，则一定使用每季度一次的截止时间；如果您唯一的法律要求是年度，则使用年度。

即使您的截止日期是季度的外部或合规目的，公司也可能会选择每月截止日期，以进行内部审核和理智(例如，将通量状态的持续时间保持在最小) )。

例如。在澳大利亚，税务办公室的业务截止时间是每季度一次，但是较大的公司每月都会截止其库存控制(这省去了长期追逐错误的麻烦)。

例如。银行每月都有法律合规要求，因此它们对这些数字进行内部审核，并每月结帐。

在原始国家和流氓国家中，出于明显的恶意目的，银行将通行状态的期限保持在最大。他们中的一些仅每年发布其合规报告。这就是为什么澳大利亚的银行不会倒闭的原因之一。

在AccountTransaction表中，请勿在“金额”列中使用负数/正数。金钱总是有正值的，没有负二十美元(或者你欠我的负五十美元)之类的东西，然后得出双重负数意味着其他东西。

的移动方向或对基金的打算是一个单独的事实(对于AccountTransaction.Amount而言)。这就需要一个单独的列(一个基准中的两个事实破坏了规范化规则，结​​果将复杂性引入了代码中)。

实现一个TransactionType引用表，该表的主键是(D, W)，以作为您的入金/出金的起点。随着系统的扩展，只需添加(A, a, F, w)作为调整功劳；调整借方；银行费用; ATM_提款;等

无需更改代码。

在某些原始国家/地区，诉讼要求规定，在任何列出“交易”的报告中，必须在每一行上显示运行总计。 (请注意，这不是审计要求，因为这些要求比[(请参见上面的方法)优越于法院要求；审计师的愚蠢程度不及律师；等等。)

显然，我不会反对法院的要求。问题是原始编码器将其转换为:哦，哦，我们必须实现AccountTransaction.CurrentBalance列。他们无法理解:

在报表上打印列的要求不是决定将值存储在数据库中

任何类型的运行总计都是派生值，并且很容易编码(如果对您不方便，请提问)。只需在报告中实现所需的代码即可。

实现运行总计，例如。 AccountTransaction.CurrentBalance作为列会导致可怕的问题:

引入了重复列，因为它是可派生的。打破规范化。引入了更新异常。

更新异常:每当历史插入事务或更改AccountTransaction.Amount时，从该日期到当前的所有AccountTransaction.CurrentBalances 都必须重新计算和更新。

在上述情况下的

(已存档供法院使用的报告)现在已过时(每份在线数据报告在打印后即已过时)。就是打印;评论;更改交易；重印;重新审核，直到满意为止。无论如何，这是没有意义的。

，这就是为什么在不那么原始的国家/地区，法院不接受任何旧的打印纸，而仅接受公开的数字的原因。银行对帐单已经受审计要求(请参阅上述方法)，并且无法撤回，更改和重新打印。

评论

Alex:
yes code would be nice to look at, thank you. Even maybe a sample "bucket shop" so people could see the starting schema once and forever, would make world much better.

对于上面的数据模型。

代码•报告当前余额

SELECT  AccountNo,
        ClosingDate = DATEADD( DD, -1 Date ), -- show last day of previous
        ClosingBalance,
        CurrentBalance = ClosingBalance + (
            SELECT SUM( Amount )
                FROM AccountTransaction
                WHERE AccountNo = @AccountNo
                    AND TransactionTypeCode IN ( "A", "D" )
                    AND DateTime >= CONVERT( CHAR(6), GETDATE(), 2 ) + "01"
                ) - (
            SELECT SUM( Amount )
                FROM AccountTransaction
                WHERE AccountNo = @AccountNo
                    AND TransactionTypeCode NOT IN ( "A", "D" )
                    AND DateTime >= CONVERT( CHAR(6), GETDATE(), 2 ) + "01"
                )
    FROM AccountStatement
    WHERE AccountNo = @AccountNo
        AND Date = CONVERT( CHAR(6), GETDATE(), 2 ) + "01"

By denormalising that transactions log I trade normal form for more convenient queries and less changes in views/materialised views when I add more tx types

神救救我。

违反标准时，您将自己置于第三世界的位置，在那些世界中不会破坏的东西，这些东西在第一世界国家永远不会破坏。

寻求权威的正确答案，然后反对它，或者为您的不合标准的方法争论，这可能不是一个好主意。

反规范化(此处)会导致更新异常，即重复的列，可以从TransactionTypeCode派生。您希望简化编码，但是您愿意在两个地方而不是一个地方进行编码。这正是容易出错的代码类型。

根据E F Codd博士的“关系模型”完全标准化的数据库提供了最简单，最逻辑，最直接的代码。 (在我的工作中，我根据契约(Contract)保证，每个报告都可以由一个SELECT提供服务。)

ENUM不是SQL。 (免费软件NONsql套件不符合SQL，但是它们确实具有SQL不需要的其他功能。)如果您的应用程序毕业于商业SQL平台，则必须将所有这些ENUMs重写为普通的LookUp表。以CHAR(1)或INT作为PK。然后，您将意识到它实际上是带有PK的表。

错误的值为零(它还具有负面影响)。真理的值(value)为一。我不会将一换成零。因此，这不是一个权衡。这只是您的开发决定。