简单银行账户的派生账户余额与存储账户余额? [英] Derived account balance vs stored account balance for a simple bank account?

问题描述

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

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

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

您建议如何就此做出决定?非常感谢！

解决方案

前言

有一个客观事实:审计要求.此外，在处理公共资金时，必须遵守立法.

您不必实施完整的会计要求，您可以仅实施您需要的部分.

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

还需要说明的是:不要聘请不合格、未经认证的审核员".会有后果，就像你聘请了一个不合格的开发人员一样.如果税务局对您罚款，情况可能会更糟.

方法

不太原始的国家的标准会计方法是这样的.其他方面的最佳实践"，如果您愿意的话.

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

考虑

首先，注意事项.

1. 切勿重复数据.
   如果可以得出当前余额(这里很简单)，不要用汇总列复制它.这样的列是重复的数据.它打破了规范化规则.此外，它创建一个更新异常，否则它不存在.

2. 如果您确实使用了汇总列，则每当交易更新时(如更改，而不是插入新交易时)，汇总列 value 就会过时，因此无论如何，它必须一直更新.这就是更新异常的结果.这消除了拥有它的价值.

3. 外部出版物.
   分开点.如果余额已公布，如在每月银行对账单中，此类文件通常具有法律限制和影响，因此公布的当前余额值在公布后不得更改.

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

     • 这种企图改变已发表历史的行为是新手的标志.新手和精神病人会坚持认为历史是可以改变的.但众所周知，对法律的无知并不构成有效的辩护.

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

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

4. 为了纠正过去发生的错误，现在正在纠正，必要的更正或调整作为当月的新交易进行(即使它适用于一些以前的交易)月或持续时间).

   这是因为该适用月份已关闭；审计；并出版，因为在历史发生并被记录之后，人们无法改变历史.唯一有效的月份是当前月份.

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

     当然，证券的利率也必须更正，以免重复该错误.

   • 如果您发现银行在计算您的储蓄(计息)账户的利息时有错误，并且您更正了错误，您将获得一笔存款，该存款构成当前的全部调整价值月.这是当月的交易.

     银行不会:改变历史；为每个历史月份申请利息；回顾历史悠久的银行对账单；重新发布历史性的银行对账单.不可以.也许在第三世界国家除外.

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

5. 所有真实的会计系统(即由适用国家审计机关认可的系统，而不是大量的米老鼠包")都使用复式记账系统进行交易，正是因为它可以防止一大堆错误，其中最重要的是，资金不会丢失".这需要总帐和复式会计.

   • 你没有要求那个，你不需要那个，所以我没有在这里描述.但请记住，以防资金丢失"，因为这是您必须实施的，而不是一些创可贴的解决方案；不是另一个未经认可的包裹".
   <块引用>

   此答案服务于所提出的问题，不是复式记账.
   有关该主题的完整处理(详细数据模型；会计事务示例；受影响的行；以及 SQL 代码示例)，请参阅此问答:
   对于关系模型或其建模方法的新手来说是必不可少的读物.请注意，IDEF1X 模型具有丰富的细节和精确度，可显示所有必需的细节，而国产模型远低于此.这意味着必须理解符号.

内容

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

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

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

   • 它有一个附加值，因为它将需要查询的交易行的范围限制为当月

     • 同样，如果您的表是关系表，AccountTransaction 的主键将是 (AccountNo, Transaction DateTime)以毫秒的速度检索交易.

     • 而对于记录归档系统，主键"将是 TransactionID，您将按交易日期检索当前月份，该日期可能已正确编入索引，也可能未正确编入索引，并且所需的行将分布在整个文件中.在任何情况下都远低于 ClusteredIndex 的速度，并且由于传播，它将导致表扫描.

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

3. 对于每个Account，CurrentBalance 是:

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

     (对于库存，PartAudit.QtyOnHand)

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

     (对于库存，PartMovement.Quantity)

   • 减去当月 AccountTransaction.Amounts 的 SUM，其中 `MovementType 表示提款.

4. 在此方法中，只有当月的AccountTransactions 处于不断变化的状态，因此它们必须导出.之前的所有月份都已发布和关闭，因此必须使用审计数据.

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

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

7. 此设计包含了所有范围级别的性能考虑(如果这不明显，请要求扩展).在数据库内部扩展不是问题，任何遗留的扩展问题都是在数据库外部.

<小时>

纠正建议

需要说明这些项目只是因为在许多 SO Answers 中提供了不正确的建议(当然，由群众投票，民主地)，并且互联网上充斥着不正确的建议(业余爱好者喜欢发表他们主观的真相"):

1. 显然，有些人不明白我在技术术语中给出了一个方法，以针对清晰的数据模型进行操作.因此，它不是特定国家/地区特定应用程序的伪代码.方法是给有能力的开发者看的，对于需要亲手带领的人来说不够详细.

   • 他们也不明白一个月的截止期是一个示例:如果您用于税务局的截止期是每季度一次，那么无论如何，请使用季度截止；如果您的唯一法律要求是每年一次，请使用每年一次.

   • 即使出于外部或合规目的您的截止日期是每季度一次，公司也很可能会选择每月截止，以用于内部审计和健全的目的(即保持状态的期限长度)通量降至最低).

     例如.在澳大利亚，税务局对企业的截止日期是每季度一次，但较大的公司每月都会停止库存控制(这样可以避免长时间追查错误).

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

   • 在原始国家和流氓国家，银行出于明显的恶意目的将其流动状态期保持在最大值.其中一些仅每年提交合规报告.这就是澳大利亚银行没有倒闭的原因之一.

2. 在AccountTransaction 表中，不要在金额列中使用负数/正数.金钱总是有正值，没有负 20 美元(或者 你欠我 50 美元)这样的事情，然后计算出双重负值意味着别的东西.

3. 移动方向，或者说你打算用资金做什么，是一个单独的和离散的事实(对于AccountTransaction.Amount).这需要一个单独的列(一个数据中的两个事实违反了规范化规则，结​​果是它给代码带来了复杂性).

   • 实现一个TransactionType参考表，其Primary Key是(D, W )，以存款/取款为起点.随着系统的增长，只需​​添加( A, a, F, w )作为调整信用；调整借记；银行费用;ATM_提款；等

   • 无需更改代码.

4. 在一些原始国家，诉讼要求规定，在任何列出交易的报告中，每一行都必须显示累计总数.(注意，这不是审计要求，因为这些要求优于 [(参考上述方法)法院要求；审计员比律师更愚蠢；等等)

   显然，我不会反对法庭要求.问题是原始编码人员将其转换为:哦，哦，我们必须实现一个 AccountTransaction.CurrentBalance column.他们不明白:

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

   • 任何类型的总和都是派生值，并且很容易编码(如果对您来说不容易，请提出问题).只需在报告中实现所需的代码即可.

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

     • 引入了一个重复的列，因为它是可推导的.打破正常化.引入更新异常.

     • 更新异常:每当历史上插入交易，或更改 AccountTransaction.Amount 时，所有 AccountTransaction.CurrentBalances 从该日期开始到现在必须重新计算和更新.

   • 在上述案例中，提交给法庭使用的报告现已过时(每份在线数据报告在打印时即已过时).IE.打印;审查;更改交易；重印;重新审核，直到您满意为止.在任何情况下都是没有意义的.

   • 这就是为什么在不太原始的国家，法院不接受任何旧的印刷纸，他们只接受已发表的数字，例如.银行对账单，已经符合审计要求(参考上述方法)，不能召回、更改和重新打印.

<小时>

评论

<块引用>

亚历克斯:
是的代码会很好看，谢谢.甚至可能是一个样本桶店"，这样人们就可以一劳永逸地看到起始模式，会让世界变得更好.

对于上面的数据模型.

代码 • 报告当前余额

SELECT AccountNo,ClosingDate = DATEADD( DD, -1 Date ), -- 显示前一天的最后一天期末余额，CurrentBalance = ClosingBalance + (选择总和(金额)来自账户交易WHERE AccountNo = @AccountNoAND TransactionTypeCode IN ( "A", "D" )AND DateTime >= CONVERT( CHAR(6), GETDATE(), 2 ) + "01") - (选择总和(金额)来自账户交易WHERE AccountNo = @AccountNoAND TransactionTypeCode NOT IN ( "A", "D" )AND DateTime >= CONVERT( CHAR(6), GETDATE(), 2 ) + "01")来自账户报表WHERE AccountNo = @AccountNoAND 日期 = CONVERT( CHAR(6), GETDATE(), 2 ) + "01"

<块引用>

通过非规范化交易日志，当我添加更多 tx 类型时，我可以交换正常形式以获得更方便的查询和更少的视图/物化视图更改

上帝帮助我.

1. 当你违反标准时，你会将自己置于第三世界的位置，在那里不应该打破的东西，在第一世界国家永远不会打破的东西.

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

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

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

3. ENUM 不是 SQL.(免费软件 NONsql 套件没有 SQL 合规性，但它们确实有 SQL 中不需要的额外功能.)如果您的应用程序升级到商业 SQL 平台，您将不得不重新编写所有这些 ENUM 作为普通的查找表.以 CHAR(1) 或 INT 作为 PK.然后你会发现它实际上是一个带有 PK 的表.

4. 一个错误的值为零(它也有负面影响).真理有一个值.我不会用一换零.因此，这不是一种权衡.这只是您的开发决定.

So, its like our normal bank accounts where we have a lot of transactions which result in inflow or outflow of money. The account balance can always be derived by simply summing up the transaction values. What would be better in this case, storing the updated account balance in the database or re-calculating it whenever needed?

Expected transaction volume per account: <5 daily

Expected retrieval of account balance: Whenever a transaction happens and once a day on an average otherwise.

How would you suggest to take a decision on this? Thanks a lot!

解决方案

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.

Method

The Standard Accounting method in not-so-primitive countries is this. The "best practice", if you will, in others.

This method applies to any system that has similar operations; needs; historic monthly figures vs current-month requirements, such as Inventory Control, etc.

Consideration

First, the considerations.

1. Never duplicate data.
   If the Current Balance can be derived (and here it is simple), do not duplicate it with a summary column. Such a column is a duplication of data. It breaks Normalisation rules. Further, it creates an Update Anomaly, which otherwise does not exist.

2. If you do use a summary column, whenever the Transactions are updated (as in changed, not as in when a new Transaction is inserted), the summary column value becomes obsolete, so it must be updated all the time anyway. That is the consequence of the Update Anomaly. Which eliminates the value of having it.

3. External publication.
   Separate point. If the balance is published, as in a monthly Bank Statement, such documents usually have legal restrictions and implications, thus that published Current Balance value must not change after publication.

   • Any change, after the publication date, in the database, of a figure that is published externally, is evidence of dishonest conduct, fraud, etc.

     • Such an act, attempting to change published history, is the hallmark of a novice. Novices and mental patients will insist that history can be changed. But as everyone should know, ignorance of the law does not constitute a valid defence.

   • You wouldn't want your bank, in Apr 2015, to change your Current Balance that they published in their Bank Statement to you of Dec 2014.

   • That figure has to be viewed as an Audit figure, published and unchangeable.

4. To correct an error that was made in the past, that is being corrected in the present, the correction or adjustment that is necessary, is made as new Transactions in the current month (even though it applies to some previous month or duration).

   This is because that applicable-to month is closed; Audited; and published, because one cannot change history after it has happened and it has been recorded. The only effective month is the current one.

   • For interest-bearing systems, etc, in not-so-primitive countries, when an error is found, and it has an historic effect (eg. you find out in Apr 2015 that the interest calculated on a security has been incorrect, since Dec 2014), the value of the corrected interest payment/deduction is calculated today, for the number of days that were in error, and the sum is inserted as a Transaction in the current month. Again, the only effective month is the current one.

     And of course, the interest rate for the security has to be corrected as well, so that that error does not repeat.

   • If you find an error in your bank's calculation of the interest on your Savings (interest-bearing) Account, and you have it corrected, you get a single deposit, that constitutes the whole adjustment value, in the current month. That is a Transaction in the current month.

     The bank does not: change history; apply interest for each of the historic months; recall the historic Bank Statements; re-publish the historic Bank Statements. No. Except maybe in third world countries.

   • The same principles apply to Inventory control systems. It maintains sanity.

5. All real accounting systems (ie. those that are accredited by the Audit Authority in the applicable country, as opposed to the Mickey Mouse "packages" that abound) use a Double Entry system for Transactions, precisely because it prevents a raft of errors, the most important of which is, funds do not get "lost". That requires a General Ledger and Double-Entry Accounting.

   • You have not asked for that, you do not need that, therefore I am not describing it here. But do remember it, in case money goes "missing", because that is what you will have to implement, not some band-aid solution; not yet another unaccredited "package".

   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.

6. The major issues that affect performance are outside the scope of this question, they are in the area of whether you implement a genuine Relational Database or not (eg. a 1960's Record Filing System, which is characterised by Record IDs, deployed in an SQL database container for convenience).

   • The use of genuine Relational Keys, etc will maintain high performance, regardless of the population of the tables.

   • Conversely, an RFS will perform badly, they simply cannot perform. "Scale" when used in the context of an RFS, is a fraudulent term: it hides the cause and seeks to address everything but the cause. Most important, such systems have none of the Relational Integrity; the Relational Power; or the Relational Speed, of a Relational system.

Implementation

Relational Data Model • Account Balance

Relational Data Model • Inventory

Notation

• All my data models are rendered in IDEF1X, the Standard for modelling Relational databases since 1993.

• My IDEF1X Introduction is essential reading for those who are new to the Relational Model, or its modelling method. Note that IDEF1X models are rich in detail and precision, showing all required details, whereas home-grown models have far less than that. Which means, the notation has to be understood.

Content

1. For each Account, there will be a ClosingBalance, in a AccountStatement table (one row per AccountNo per month), along with Statement Date (usually the first day of the month) and other Statement details.

   • This is not a duplicate because it is demanded for Audit and sanity purposes.

     For Inventory, it is a QtyOnHand column, in the PartAudit table (one row per PartCode per month)

   • It has an additional value, in that it constrains the scope of the Transaction rows required to be queried to the current month

     • Again, if your table is Relational, the Primary Key for AccountTransaction will be (AccountNo, Transaction DateTime) which will retrieve the Transactions at millisecond speeds.

     • Whereas for a Record Filing System, the "primary key" will be TransactionID, and you will be retrieving the current month by Transaction Date, which may or may not be indexed correctly, and the rows required will be spread across the file. In any case at far less than ClusteredIndex speeds, and due to the spread, it will incur a tablescan.

2. The AccountTransaction table remains simple (the real world notion of a bank account Transaction is simple). It has a single positive Amount column.

3. For each Account, the CurrentBalance is:

   • the AccountStatement.ClosingBalance of the previous month, dated the first of the next month for convenience

     (for inventory, the PartAudit.QtyOnHand)

   • plus the SUM of the AccountTransaction.Amounts in the current month, where the TransactionType indicates a deposit

     (for inventory, the PartMovement.Quantity)

   • minus the SUM of the AccountTransaction.Amounts in the current month, where the `MovementType indicates a withdrawal.

4. In this Method, the AccountTransactions in the current month, only, are in a state of flux, thus they must be derived. All previous months are published and closed, thus the Audit figure must be used.

5. The older rows in the AccountTransaction table can be purged. Older than ten years for public money, five years otherwise, one year for hobby club systems.

6. Of course, it is essential that any code relating to accounting systems uses genuine OLTP Standards and genuine SQL ACID Transactions.

7. This design incorporates all scope-level performance considerations (if this is not obvious, please ask for expansion). Scaling inside the database is a non-issue, any scaling issues that remain are honestly outside database.

---

Corrective Advice

These items need to be stated only because incorrect advice has been provided in many SO Answers (and up-voted by the masses, democratically, of course), and the internet is chock-full of incorrect advice (amateurs love to publish their subjective "truths"):

1. Evidently, some people do not understand that I have given a Method in technical terms, to operate against a clear data model. As such, it is not pseudo-code for a specific application in a specific country. The Method is for capable developers, it is not detailed enough for those who need to be lead by the hand.

   • They also do not understand that the cut-off period of a month is an example: if your cut-off for Tax Office purposes is quarterly, then by all means, use a quarterly cut-off; if the only legal requirement you have is annual, use annual.

   • Even if your cut-off is quarterly for external or compliance purposes, the company may well choose a monthly cut-off, for internal Audit and sanity purposes (ie. to keep the length of the period of the state of flux to a minimum).

     Eg. in Australia, the Tax Office cut-off for businesses is quarterly, but larger companies cut-off their inventory control monthly (this saves having to chase errors over a long period).

     Eg. banks have legal compliance requirements monthly, therefore they perform an internal Audit on the figures, and close the books, monthly.

   • In primitive countries and rogue states, banks keep their state-of-flux period at the maximum, for obvious nefarious purposes. Some of them only make their compliance reports annually. That is one reason why the banks in Australia do not fail.

2. In the AccountTransaction table, do not use negative/positive in the Amount column. Money always has a positive value, there is no such thing as negative twenty dollars (or that you owe me minus fifty dollars), and then working out that the double negatives mean something else.

3. The movement direction, or what you are going to do with the funds, is a separate and discrete fact (to the AccountTransaction.Amount). Which requires a separate column (two facts in one datum breaks Normalisation rules, with the consequence that it introduces complexity into the code).

   • Implement a TransactionType reference table, the Primary Key of which is (D, W ) for Deposit/Withdrawal as your starting point. As the system grows, simply add ( A, a, F, w ) for Adjustment Credit; Adjustment Debit; Bank Fee; ATM_Withdrawal; etc.

   • No code changes required.

4. In some primitive countries, litigation requirements state that in any report that lists Transactions, a running total must be shown on every line. (Note, this is not an Audit requirement because those are superior [(refer Method above) to the court requirement; Auditors are somewhat less stupid than lawyers; etc.)

   Obviously, I would not argue with a court requirement. The problem is that primitive coders translate that into: oh, oh, we must implement a AccountTransaction.CurrentBalance column. They fail to understand that:

   • the requirement to print a column on a report is not a dictate to store a value in the database

   • a running total of any kind is a derived value, and it is easily coded (post a question if it isn't easy for you). Just implement the required code in the report.

   • implementing the running total eg. AccountTransaction.CurrentBalance as a column causes horrendous problems:

     • introduces a duplicated column, because it is derivable. Breaks Normalisation. Introduces an Update Anomaly.

     • the Update Anomaly: whenever a Transaction is inserted historically, or a AccountTransaction.Amount is changed, all the AccountTransaction.CurrentBalances from that date to the present have to be re-computed and updated.

   • in the above case, the report that was filed for court use, is now obsolete (every report of online data is obsolete the moment it is printed). Ie. print; review; change the Transaction; re-print; re-review, until you are happy. It is meaningless in any case.

   • which is why, in less-primitive countries, the courts do not accept any old printed paper, they accept only published figures, eg. Bank Statements, which are already subject to Audit requirements (refer the Method above), and which cannot be recalled or changed and re-printed.

---

Comments

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.

For the data model above.

Code • Report Current Balance

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

God help me.

1. When you go against Standards, you place yourself in a third-world position, where things that are not supposed to break, that never break in first-world countries, break.

   It is probably not a good idea to seek the right answer from an authority, and then argue against it, or argue for your sub-standard method.

2. Denormalising (here) causes an Update Anomaly, the duplicated column, that can be derived from TransactionTypeCode. You want ease of coding, but you are willing to code it in two places, rather than one. That is exactly the kind of code that is prone to errors.

   A database that is fully Normalised according to Dr E F Codd's Relational Model provides for the easiest, the most logical, straight-forward code. (In my work, I contractually guarantee every report can be serviced by a single SELECT.)

3. ENUM is not SQL. (The freeware NONsql suites have no SQL compliance, but they do have extras which are not required in SQL.) If ever your app graduates to a commercial SQL platform, you will have to re-write all those ENUMs as ordinary LookUp tables. With a CHAR(1) or a INT as the PK. Then you will appreciate that it is actually a table with a PK.

4. An error has a value of zero (it also has negative consequences). A truth has a value of one. I would not trade a one for a zero. Therefore it is not a trade-off. It is just your development decision.

这篇关于简单银行账户的派生账户余额与存储账户余额?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！