Question

I am looking to design a database for a website where users will be able to gain points (reputation) for performing certain activities and am struggling with the database design.

I am planning to keep records of the things a user does so they may have 25 points for an item they have submitted, 1 point each for 30 comments they have made and another 10 bonus points for being awesome!

Clearly all the data will be there, but it seems like a lot or querying to get the total score for each user which I would like to display next to their username (in the form of a level). For example, a query to the submitted items table to get the scores for each item from that user, a query to the comments table etc. If all this needs to be done for every user mentioned on a page…. LOTS of queries!

I had considered keeping a score in the user table, which would seem a lot quicker to look up, but I’ve had it drummed into me that storing data that can be calculated from other data is BAD!

I’ve seen a lot of sites that do similar things (even stack overflow does similar) so I figure there must be a “best practice” to follow. Can anyone suggest what it may be?

Any suggestions or comments would be great. Thanks!

Answer 1

I think that this is definitely a great question. I’ve had to build systems that have similar behavior to this–especially when the table with the scores in it is accessed pretty often (like in your scenario). Here’s my suggestion to you:

First, create some tables like the following (I’m using SQL Server best practices, but name them however you see fit):

UserAccount          UserAchievement
 -Guid (PK)           -Guid (PK)
 -FirstName           -UserAccountGuid (FK)
 -LastName            -Name
 -EmailAddress        -Score

Once you’ve done this, go ahead and create a view that looks something like the following (no, I haven’t verified this SQL, but it should be a good start):

SELECT [UserAccount].[FirstName]      AS FirstName,
       [UserAccount].[LastName]       AS LastName,
       SUM([UserAchievement].[Score]) AS TotalPoints
FROM [UserAccount]
INNER JOIN [UserAchievement]
     ON [UserAccount].[Guid] = [UserAchievement].[UserAccountGuid]
GROUP BY [UserAccount].[FirstName],
         [UserAccount].[LastName]
ORDER BY [UserAccount].[LastName] ASC

I know you’ve mentioned some concern about performance and a lot of queries, but if you build out a view like this, you won’t ever need more than one. I recommend not making this a materialized view; instead, just index your tables so that the lookups that you need (essentially, UserAccountGuid) will enable fast summation across the table.

I will add one more point–if your UserAccount table gets huge, you may consider a slightly more intelligent query that would incorporate the names of the accounts you need to get roll-ups for. This will make it possible not to return huge data sets to your web site when you’re only showing, you know, 3-10 users’ information on the page. I’d have to think a bit more about how to do this elegantly, but I’d suggest staying away from “IN” statements since this will invoke a linear search of the table.