12 ms·
> Don't store the account data. Instead store the transactions. Compute the accounts from that. The table "Transactions" should have the fields: Date, Amount, S
by Mister_Snuggles 3y ago
> Don't store the account data. Instead store the transactions. Compute the accounts from that. The table "Transactions" should have the fields: Date, Amount, SourceAccount, TargetAccount, Description.
This is a bad design, please don't do this.
The better design is to have header and detail tables:
Header: TransactionID, Date, Description, (other fields as required, e.g., posting status, reconciliation status, etc)
Detail: TransactionID, LineNumber, Account, Amount, Description, (other fields as required, e.g., reference numbers for subledgers, etc)
This allows a transaction to affect any number of accounts. In effect, the transaction ends up reflecting a business transaction which may affect many accounts.
- EvanAnderson 3y agoI don't think you're saying anything different than the parent poster, fundamentally. You're both saying "event-source the totals". You're adding an abstraction to enable more flexibility and functionality. That doesn't change the fundamental event-sourced nature of totals.
- BillyTheKing 3y agoyes, that's the gnu cash implementation (also used by formance for example) - I don't love it tbh, yes you can add multiple postings under a single transaction, but.. if you look at one of those postings, or just the transaction in general you don't directly know which posting originates from what account, you have to sorta map it based on amounts
- superzamp 3y agoJumping-in as I happen to know formance very well; I'm 100% agreeing with the need to know what posting originates from what account, which is why formance transaction format is essentially a container for postings, which themselves are a quantified, directed relation between exactly 2 accounts. So a transaction can indeed impact N >= 2 accounts, but a posting within a transaction will always relate exactly 2 accounts.