|
|
|
|
|
|
by cstejerean
1232 days ago
|
|
|
I think they key part is "distributed financial accounting database". For anything that didn't need to be distributed to handle massive volume of transactions I'd also pick Postgres, but I can imagine there's a limit where that wouldn't work, and as soon as you need to do this in a distributed database things get exciting. No experience with the linked gem but the description states > While this gem acts like a double-entry bookkeeping system, as it creates two entries in the database for each transfer, it does not enforce accounting rules. And that seems like a far cry from things like "rejecting transfers if the accounts involved would exceed their net debit or credit balances". |
|
|
> And that seems like a far cry from things like "rejecting transfers if the accounts involved would exceed their net debit or credit balances".
The READEME needs to be updated[1] for clarity. It doesn't enforce "accounting" rules, however The DoubleEntry gem has rules to optionally ensure a balance cannot go negative, and it also has an allowlist of allowed transfers ( which are defined by source account, dest account and code ).
[1] https://github.com/envato/double_entry/pull/216/files
> I think they key part is "distributed financial accounting database". For anything that didn't need to be distributed to handle massive volume of transactions I'd also pick Postgres, but I can imagine there's a limit where that wouldn't work, and as soon as you need to do this in a distributed database things get exciting.
That is why I qualified my statement with "you're using Postgres for your main app db".
For every financial transaction you'd likely have many more business logic level transactions, and you would want your business transactions to be as consistent as your financial transactions. No point storing a financial transfer if you can't match it up with a purchase on your business db.