I think you can expand this explanation with database terminology.
In modern RDBMS, you could have naive implementation with two account's balance, and increment one decrement the other. But without transactions it just isn't safe, its better to have one row in a table with a debit and credit.
Now if you're doing accounts by hand you really need that single line transaction record.
> its better to have one row in a table with a debit and credit.
No. Some transactions have 3 lines, eg: two debits and one credit. Some examples:
- Split payment at a shop, $100 item bought with $70 cheque and $30 cash would be
credit sales $100
debit cash $30
debit bank $70
Now if you introduce sales tax or VAT/GST, its more complicated. Say the $100 item is actually $90 + $10 VAT, then entries goes:
credit sales $90
credit vat-payable $10
debit cash $30
debit bank $70
I saw some systems that used single line, even in these cases. It had an ephemeral/transitory account to help on this.
And to map it together, all these entries would be related to a single transaction.
It seemed a nice solution for me.
In modern RDBMS, you could have naive implementation with two account's balance, and increment one decrement the other. But without transactions it just isn't safe, its better to have one row in a table with a debit and credit.
Now if you're doing accounts by hand you really need that single line transaction record.