让我们举个例子，看看在两种情况下如何实现。
考虑帐户
Cash和帐户Rent。当我支付每月租金时，我将从我的Cash帐户中转移$ 100到我的Rent帐户中。每笔交易一行
在单行系统中，此类交易将被存储as：
事务
tx_id | posting_date
1 | 23/05/2015
transaction_records
id | tx_id | credit_account | debit_account | amount
1 | 1 | Cash | Rent | 100.00
每个事务两行
在两行系统中，我必须镜像同一笔交易记录以创建相反的记录，一旦我对两者进行总结，我将得到零余额。 >交易
tx_id | posting_date
1 | 23/05/2015
交易记录
id | tx_id | type | account | amount
1 | 1 | credit | Cash | 100.00
2 | 1 | debit | Rent | 100.00
问题
首先我想指出：我同时拥有
transactions和transaction_records表（而不是一个表）的原因是能够处理拆分交易（在这种情况下，我从Cash帐户中将100美元转帐到两个或多个不同的帐户）。 /> 最初，我尝试以每笔交易一行来实现这一点，但要计算帐户余额非常麻烦，并实际检索数据。
我倾向于第二种情况；但是，它也存在一些问题：
如何更新单个记录？假设我犯了一个错误，我没有记录$ 100的房租，而是记录了$ 10。我现在有2个
transaction_records-一个用于贷记，一个用于借记，两者的金额均为$ 10。现在，我进行对帐，并且想解决此错字。我将如何在数据库中解决此问题？我不知道记录之间的联系，如果发生拆分，则一个事务可以有两个以上的记录。我想出的唯一解决方案是为每个记录对添加一些
ref_id，它们将在特定tx_id的上下文内唯一地将这些记录标识为“彼此相反的一面”。更好/更简单？为了简化我的问题：我想代表从帐户A到帐户B的资金流动。我给出的两种情况都是存储此类交易的有效设计。正如我还指出的那样，它们都有优点和缺点（第一个优点：更易于保存，更难检索；第二个缺点则相反）。
他们可能还有其他优点/缺点，但我没有发现对现在，因此我要向更有经验的人提出意见。
#1 楼
实际上，所建议的单行记帐模式允许进行适当的重复记账（以始终指定借记和贷记的帐户），而不会引入“金额”数据的冗余。双重条目的实现，该双重条目通过构造来平衡，因此不可能“失去平衡”。机器可以即时重新计算分类帐。您必须做2个选择而不是一个选择才能检索分类帐。
请注意，除交易拆分外，还有其他交易（例如外汇）可能会产生2条记录而不是4。这完全取决于您是否要对非规范化进行一点处理，只需输入4个具有类似描述的事务即可。
您可以阻止任何事务的输入或修改以维护审计追踪，如果您这样做希望能够审核事务日志。
在上述主题中，对于CPA，“完全规范化”似乎表示所有会计师都认可的规则，而对于程序员而言，它具有不同的含义，即没有派生或多余的含义。
所有会计数据都是一组交易，这些交易给出金额，流量所来源和往来的帐户以及日期，一些说明（和其他附件）。分类帐和余额是通过求和从此交易数据得出的简单视图。
评论
我喜欢简单的方法……“会计数据只不过是一组交易，这些交易给出了金额，所流向的帐户，日期以及一些描述”。让我们不要过于复杂。
–查尔斯·哈蒙（Charles Harmon）
17年5月4日在17:58
我喜欢您建议不要修改交易记录。一旦创建了记录，它就会被扔在石头上。这就是为什么我们有贷方和借方票据以及其他适当的会计方法来修复此类错误的原因
–彼得
17年9月9日在20:05
重复录入簿记不是为了更容易发现错误的要点之一吗？从这种意义上讲，单行更容易出错。如果将错别字排成一行，则不会发出警告。但是，如果您将错字排成两行的一排，您将立即知道帐户不平衡。
– cammil
20 Mar 20 '20 at 18:11
完全同意“禁止编辑”规则。看来，如果仅将它们附加，则可以避免许多潜在的问题。
– cammil
20 Mar 20 '20 at 18:13
#2 楼
日记帐是会计系统中指定类型的所有交易的按时间顺序列出的清单。这是一个简单的销售（基于帐户）日记帐的分类帐上的经典演示：
请注意，每行都是单个交易，总借方=总贷方;并且每笔交易都击中相同的三个帐户。现金销售日记帐看起来类似，但用一个标有“现金借方”的“应收帐款借方”列代替。现金支出日记帐的第一列将标记为现金信用，其他列例如应付帐款借方和员工费用借方。
数百年来，这种演示都是标准的，直到几十年前个人计算机变得负担得起。通过简单地检查每一行，可以轻松验证每个事务是否平衡，这具有显着的优势。同样，在将此类交易的页面发布到分类帐之前，可以类似地验证页面总数。那是许多会计系统中使用的批处理模型。
很容易看出，当从字面意义上转换为自动化系统时，此纸模型具有明显的缺点：
数据结构是一种关键数据结构，而经验表明，对折叠数据结构进行编程要简单得多（也更健壮，更容易验证）。并且
由于每个专业日记帐都使用不同的帐户集，因此每个此类日记帐都必须分别设计和编程，这是浪费和容易出错的活动。由于这些原因，通常建议使用“专业日记帐”设计作为会计系统的接口，但设计一个可以作为多个日记帐的数字存储库的数据结构。在现代RDBMS中，这具有潜在的优势，即总账，甚至专门的子账本都可以成为日记帐上的索引视图，从而完全消除了对过帐流程进行编码的要求（日记帐交易被锁定并拥有其帐户的步骤
无论您最终得到什么数据设计，关键是要为每种交易类型（即等效纸张系统中的每个专业日记帐）创建一个单独的过帐条目，并在其中保持平衡
我的观点是，您提出的两种方法都是重复记录簿记的不可靠机制。第一点：出于充分的理由，日记帐是一次写入表。有时，两个虚拟表Pending Entries和Posted Entries并置在单个数据结构中，但是IsPosted位始终为只写状态，系统必须确保保持Posted Entries记录的只读性质。
过去800年中，会计师发布日记帐分录的方式已完全标准化。纸质演示文稿和声音电子演示文稿之间的唯一区别是，在后一种情况下，折叠桌结构更方便，而在前一种情况下，枢轴桌结构更方便，这在历史上在需要高度并行处理时最为重要-即每个职员都有很多职员。维护单个或少量的专业期刊。历史上只有控制员拥有《通用日志》的权限。
请仔细注意，在上文中，我指定日记帐分录已完全规范化；日记帐分录是所有事务的按时间顺序记录，并按每种事务类型分类在日记帐中。将日记帐分录过帐到分类帐是一项单独的工作，并且虽然完全进行了规范化，但却是日记帐分录的冗余副本，其中按帐户汇总了所有交易（总分类帐）或明细（子分类帐）。 Journals和Ledgers都独立地进行两次记账。
@Codism任何会计系统，例如DEB或SEB，都可以为您记录的所有帐户提供通用报告。注意，在内部，从定义上讲，子分类账是单项簿记记录；另一侧是资产负债表上的相应控制帐户。 DEB确保对资产的每一美元都有准确的资产商业债权记录，即资产中的权益（无论是债务权益（aka负债）还是所有权权益），以及这些债权的优先级（如果有）组织破产。
评论
您能举一个您可能会推荐的表结构示例，并且不遭受所提到的缺陷的困扰吗？我不确定我是否正确理解了您的建议！
– cammil
20 Mar 20 '20 at 18:27
#3 楼
我是否可以建议您看一下该领域中的开源软件宝库？谷歌的“开源双重记账软件”提供了几种有希望的调查途径。 1和2），最后是会计软件Wiki，其中包含关于自由软件的部分。以及如何编写适合您自己特定需求的模式和/或软件的指示。
评论
您到底使用了什么方法？@johan我选择了第一种方法，其中每笔交易有一行。我添加了触发器来为交易中涉及的每个帐户正确更新余额（添加，更新或删除交易时），因此这解决了我使用此方法的主要问题。