Question

I’m stumped on the ideal method of dealing with a relatively large number of table fields, and whether or not they should be split off into separate relational tables.

I’ve got a set of tables for a web-based game of sorts, holding player data, item data, class data, etc. For each one of these (player/item/class) I also need to record a number of stats (i.e. health, spirit, armor, etc.). Currently the list is 25 stats, which means each of these tables have 50 additional columns (type/value pairs), in addition to the columns they already have.

This is starting to feel cumbersome.

The alternative is to move all stats into separate tables. For example, items stats with be in a “item stats relation” table, with IDs linking into the item and stat tables.

This would simplify the table structure and give flexibility if I ever need to change the number of stats. However, it also adds to the complexity of maintaining the data. If I add a new item, rather than just inserting a single row into the item table, I now have to insert many more rows into the “item stat relation” table to include all of the stats it needs.

Is it worth the extra effort to keep the tables simple?

---

Edit: Forgot to add the other alternative I was considering: serializing all stats into a VARCHAR or TEXT column. This too would give me flexibility to add any number of stats (especially if I used TEXT), and doesn’t add any complexity to the code that handles it. However, from what I’ve read, TEXT blocks are bad for performance, and I’d have to access it fairly frequently, reading and writing the entire block every time.

Answer 1

The alternative is to move all stats into separate tables. For example, items stats with be in a “item stats relation” table, with IDs linking into the item and stat tables.

This is the correct method of dealing with the business rules.

If I add a new item, rather than just inserting a single row into the item table, I now have to insert many more rows into the “item stat relation” table to include all of the stats it needs.

Only if that item actually uses the stat. It allows an item/etc to have 0+ stats associated, and means that you would never have to update the data model for every new stat to add a column.

There’s no performance benefit when you risk bad data. What you would make, will be eaten by the hacks you have to perform to get things to work.

…use MySQL functions over multiple items (i.e. to add up the “Strength” of all items owned by a Player), if some of those items don’t even have a record for that stat…

Use:

   SELECT IFNULL(SUM(t.value), 0)
     FROM PLAYERS p
     JOIN ITEM_STAT_RELATION itr ON itr.player_id = t.player_id
LEFT JOIN STATS s ON s.stat_id = itr.stat_id
    WHERE p.player_id = ?
      AND ...

The LEFT JOIN is used to indicate that a supporting record may not exist, and the IFNULL is meant to handle such a situation because it’s value would be null. SUM can handle NULLs – it interprets the value to be zero.

…serializing all stats into a VARCHAR or TEXT column.

Don’t do this
Concatenating a list of stats will be a pain to pull out details if you want to report on a specific stat or group of stats. Due to character limits, it runs the risk of not being able to store every stat within a single column.