Question

I use a JDBC/Derby to store highscore data for a puzzle game I am writing. Due to the nature of the game, it will be useful to be able to look at the highscore data based on filters (i.e. show me my highest scores on this level, show me the highest scores on this computer, etc.)

This game also has a “campaign” mode, where the player works toward goals and unlocks achievements.

Currently the campaign data is stored in a Serializable java file that I write out to disk.

However, since the high score data is stored in a database, and because the PlayerID in the highscore table is going to be linked to the campaign file, it feels like I should also be storing the campaign data in the database.

The problem I’m facing is that I can’t break the data down at all. It seems to me that the “Player” table is going to be a hundred+ wide, each column representing the status of a goal or achievement.

I’m not a database guy. I don’t know if this is horrible design or not. I have read about normal forms 1-5, and I believe that I am in compliance with each form, but I’m suspicious that I’m Doing Something Wrong.

I really want the high scores in a database, and they fit perfectly. As a side effect, however, I am feeling a strong push to store the campaign booleans / other info in the database as well. It feels weird to have some data written to files, and other data written to the database, especially when the two things reference each other.

Am I doing something Wrong? Is it OK to have a table with a hundred or two columns as long as it’s actually obeying the normal forms?

Answer 1

If most of the columns in the Player table represent the status of a goal or achievement, you could consider that repeating data and model it in child table.

Player Table
PlayerId (primary key)
PlayerName

Goals Table
GoalId (primary key)
GoalName

PlayerGoals Table
GoalId (primary key, foreign key to Goal)
PlayerId (primary key, foreign key to Player)

The Goals table is a master list, which you setup once when you write the game.
When a player achieves something, you insert a row into PlayerGoals.

You should model your data based on the expected use cases. Modelling it in this way (compared to a many-column Players table) will make these types of queries easier to write:-

• List players along with how many goals they have completed
• Which goal has been completed by the most players?
• Any other queries which treat Goals generically

It would be easier to add a goal because it becomes a matter of inserting a row into the Goals table rather than adding a column. However, maybe you need to write a bunch of code anyway and this is of no significance.

On the other hand, these types of queries will be easier if you have one big flat Player table with many columns:-

• Get me everything about a particular Player
• List every player that has completed Goal X
• List every player that has completed Goal X and not Goal Y

In the end, you need to choose if you want to make the concept of Goals something that you model explicitly in the database or not. What is right and wrong depends on your priorities.