You can also design your schema using unified ledger accounting (https://en.wikipedia.org/wiki/Unified_ledger_accounting) which captures both the transaction's debit and credit in a single row in a single table negating the need for a transaction.

The problem comes with trying to quickly find the balance of sub-accounts. It is common to need to find the balance of all of the general ledger accounts repeatedly and quickly when preparing accounts, or having to find all customer balances to see who has paid. Once you have 10m rows of data (easily done at an sme) this gets very slow indeed. It is common to have a second table that records running balances or balances at period ends to speed this up. This is why transactions are important or you find the individual accounts of the sales ledger control don't add up to the total. Some systems have an 'audit' tool that adds them all back up from the general ledger.

If you're interested, you can always check out the code to GNUcash;

IIRC it has a SQL Schema that can be imported into most databases.

https://wiki.gnucash.org/wiki/SQL

Ah that makes sense. Thanks!