7 ms·

Source/destination seems fail on actual DB implementation. How to sum all entries for a particular account? It could be on either side. It complicates queries a

by bvrmn 2y ago

Source/destination seems fail on actual DB implementation. How to sum all entries for a particular account? It could be on either side. It complicates queries and could trigger unoptimal query plans.

kdmtctl 2y ago
An account could be only on one side. The side and chapter is the meaning of this account. Account on the left just negates the increase/decrease direction. In a bank ledger when a loan appears on a checking account, both increased. Loan on the left, checking on the right. DT Loan → CT Checking. Loan is an asset for a bank, Clients money is a liability. On a client's balance sheet everything is mirrored. Checking is an asset, Loan is a liability. Queries are quite simple. Volumes are problematic. In a big institution you would find several ledgers included in the general ledger by totals. You just don't need all the details in one place.
- bvrmn 2y ago
  As I understand parent comment it assumes following transaction records: (source_account, dest_account, amount). I argue it complicates things. You talk more about how to make db data simultaneously a representation of final reports. I believe it's not related to this thread.
  - kdmtctl 2y ago
    You’re right. Missed it while scrolling. Regarding the parent discussion, a classic statement is also two-sided. So, you need to collect sources (debit) and destinations (credit). It is definitely possible to make each side of transaction a different record, but you have to link them, so there would be another ID for a transaction to group later. It is always there in any case, but you are either joining while getting a balance or grouping while reconstructing transactions for reports. So, it depends on the primary load: lots of transactions to register or lots of reports to provide. Both are used.

7 ms·

Source/destination seems fail on actual DB implementation. How to sum all entries for a particular account? It could be on either side. It complicates queries a

by bvrmn 2y ago

Source/destination seems fail on actual DB implementation. How to sum all entries for a particular account? It could be on either side. It complicates queries and could trigger unoptimal query plans.

kdmtctl 2y ago
An account could be only on one side. The side and chapter is the meaning of this account. Account on the left just negates the increase/decrease direction. In a bank ledger when a loan appears on a checking account, both increased. Loan on the left, checking on the right. DT Loan → CT Checking. Loan is an asset for a bank, Clients money is a liability. On a client's balance sheet everything is mirrored. Checking is an asset, Loan is a liability. Queries are quite simple. Volumes are problematic. In a big institution you would find several ledgers included in the general ledger by totals. You just don't need all the details in one place.
- bvrmn 2y ago
  As I understand parent comment it assumes following transaction records: (source_account, dest_account, amount). I argue it complicates things. You talk more about how to make db data simultaneously a representation of final reports. I believe it's not related to this thread.
  - kdmtctl 2y ago
    You’re right. Missed it while scrolling. Regarding the parent discussion, a classic statement is also two-sided. So, you need to collect sources (debit) and destinations (credit). It is definitely possible to make each side of transaction a different record, but you have to link them, so there would be another ID for a transaction to group later. It is always there in any case, but you are either joining while getting a balance or grouping while reconstructing transactions for reports. So, it depends on the primary load: lots of transactions to register or lots of reports to provide. Both are used.