3 ms·
Barring performance/memory/misc concerns, this seems pretty much the same as I'd design it. If I understand your problem correctly, you have two facts: user ma
by qsort 4y ago
Barring performance/memory/misc concerns, this seems pretty much the same as I'd design it.
If I understand your problem correctly, you have two facts: user makes a payment (account gets credited) and user consumes credits (account gets debited). Everything else is a dimension (accounts, rates).
The only choice you have to make is how you deal with changing rates. You can write the premultiplied amount on the debit table, or you can treat rates as a slowly changing dimension and decompose "amount" into "time" and the foreign key to the rate table.
Which one is better depends on what the application is doing, there's nothing wrong in principle with either.
- punkpeye 4y agoIf I learned one thing from designing is similar systems in the past is to avoid referential data as much as possible haha I did not go into such depth here, but individual function calls record (duration, billing_rate, total_cost) as plain values and also references `billing_rate` used (setting foreign constraint to restrict to avoid accidentally nuking data). Had at least one instance where an engineer in our team modified a value in rates table causing havoc to the entire billing system that relied on referential values used to calculate balances I want to build in as much redundancy as possible, even if that means duplicating data in several places