Right now creating a new service that will integrate into our company’s existing platform. The service will be responsible for tracking “points” that a user can generate over time through certain activities.
I am caught between two different methods of approach. I’m not sure whether to choose one of the following structures to continually manage points:
- Create a “log” of points and instead keep one running total in the database, like a key/value field, where the value is the current points balance that is simply adjusted during each transaction.
- Create a “ledger” system where each time the points are recalculated after a certain condition, but the entire ledger is assessed to determine the most up-to-date points balance.
Don’t think it’s relevant, but the backend DB is Riak.
Which has the least drawbacks, or is there a better way? How does the StackExchange point system work in relation to the above? Many thanks for the input!
1
This isn’t an either/or matter.
One thing that is pretty common in accounting systems is to implement a log-based system, but one with historical “closing balances” listed periodically, often in another table. The closing balances can then serve as a roll-forward point in a report. The benefits of such an approach is:
-
You can purge old data if you need to after x years.
-
Your reports don’t have to aggregate more than an amount of data since the last data maintenance window closed and the old data is now read only).
In an RDBMS (not so sure about Riak), one would also have to have logic to prevent older records from being inserted before the roll-forward points.