Question

I am currently working on a small app where users accrue points by completing tasks. What I would like is some advise on the best way to design my database tables. In some ways the system is similar to SO, users complete tasks (on SO thy answer questions) and then their point a balance is updated.

I currently have a users table that stores the usual user information, but don’t know how to take it forward.

Am I best to have a points table (user has many points) and then add user_id and points amount; then when querying a users points, pull out all points with a given user_id and sum them?

Is there a more efficient way of doing this?

Thanks,

Jack

Answer 1

The extra points table is a fair approach as it allows to track the reasons for earned points. Depending on the number of users, point transactions, and the used server, I would consider holding a few commonly needed aggregates: Most commonly the users total points.

To insert new point records in the points table you could use a stored procedure that not only records the points in the points table but also increases the points aggregate for each user. This aggregate could be held in a separate column in the users table (as suggested by Oded).

As your design advances there might appear new useful aggregates that could be precomputed.

But to keep things simple: Only use these aggregates if absolutely necessary, as for example computing the total points of a user takes too long. For a small system this really should not be a problem to calculate these totals on the fly.