> how much money out user accounts have in this microsecond
My understanding is that if you want aggregations or sub accounts then you need to duplicate transactions and maintain them yourself. This may seem like it would be annoying, but I suspect it would mostly be a matter of code organization.
I expect typical TigerBeetle (TB) clients will develop and maintain an application-level library that builds up a set of TB transactions that encode each business-level transaction. For example, if a "business transaction" is "marking a purchase order as received", the corresponding set of TB transactions might include: 1. moving the received qty from the pending receipt qty account to the inventory qty account for the received line items, 2. adding the total cost to the inventory value account for this item, 3. adding the price to the Accounts Payable (AP) account for this vendor, 4. adding the shipping price to the AP account for the delivery company, etc. But then you might want some aggregations, so you'd do the same thing again and add the price to the "total inventory value" and "total accounts payable" accounts, etc.
In fact you might want 3, 4 or even more parallel ledgers at different levels of aggregation, which could all be maintained within the application library. I wonder if there's a name for this technique. My only concern is that if you break down your business transaction into fine grained detail like this and then duplicate it with multiple aggregations then that 8000 transaction limit starts looking a lot smaller.
My understanding is that if you want aggregations or sub accounts then you need to duplicate transactions and maintain them yourself. This may seem like it would be annoying, but I suspect it would mostly be a matter of code organization.
I expect typical TigerBeetle (TB) clients will develop and maintain an application-level library that builds up a set of TB transactions that encode each business-level transaction. For example, if a "business transaction" is "marking a purchase order as received", the corresponding set of TB transactions might include: 1. moving the received qty from the pending receipt qty account to the inventory qty account for the received line items, 2. adding the total cost to the inventory value account for this item, 3. adding the price to the Accounts Payable (AP) account for this vendor, 4. adding the shipping price to the AP account for the delivery company, etc. But then you might want some aggregations, so you'd do the same thing again and add the price to the "total inventory value" and "total accounts payable" accounts, etc.
In fact you might want 3, 4 or even more parallel ledgers at different levels of aggregation, which could all be maintained within the application library. I wonder if there's a name for this technique. My only concern is that if you break down your business transaction into fine grained detail like this and then duplicate it with multiple aggregations then that 8000 transaction limit starts looking a lot smaller.