Question

I have been over this issue for the last year or so, changing what I am doing and trying different things. The issue is to do with the schema so I can still order nicely in player/clan ladders but if we want to add a stat later it won’t lock our table changing every row due to one stat per column.

I see two options for how to do this but both don’t seem to be right. One is one stat per column. There would be 4 tables, user_stat_summary (for basic stats shown on ladders), user_stat_beast (teams are human vs beast), user_stat_human and user_stat_overall. Stats are shown everywhere from the last 30 days. A cron job will take any dated stats by getting a query on matches that happened after the 30 days and taking away those stats from the 3 main tables and putting them into the overall one. Matches will have blobs for the stats each player got for that match. The issue I see here is when we have a lot of rows that we can’t easily add more stats when say the game changes a little. What I was thinking was a extra_stats blob column on each table and if we add new stats they simply aren’t going to be sortable on the ladders.

The other option is an EAV model which is what I have been playing around with but can’t seem to get it right. I would be getting many more rows per query and then grouping them into users and the order would work for the most part but I couldn’t get limits right for pagination since there was generally an unknown number of rows selected.

What I was thinking is the EAV model with a table that stores ranks per stats which could be used for ordering. So the EAV tables are currently as follows…

CREATE TABLE `user_stat` (
    `user_id` int(10) unsigned NOT NULL,
    `stat_id` varchar(50) NOT NULL,
    `value` int(10) unsigned NOT NULL,
    PRIMARY KEY (`user_id`,`stat_id`),
    CONSTRAINT `user` FOREIGN KEY (`user_id`) REFERENCES `xf_user` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

CREATE TABLE `user_human_stat` (
     `user_id` int(10) unsigned NOT NULL,
     `stat_id` varchar(50) NOT NULL,
     `value` int(10) unsigned NOT NULL,
     PRIMARY KEY (`user_id`,`stat_id`),
     CONSTRAINT `human_user` FOREIGN KEY (`user_id`) REFERENCES `xf_user` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

CREATE TABLE `user_beast_stat` (
     `user_id` int(10) unsigned NOT NULL,
     `stat_id` varchar(50) NOT NULL,
     `value` int(10) unsigned NOT NULL,
     PRIMARY KEY (`user_id`,`stat_id`),
     CONSTRAINT `beast_user` FOREIGN KEY (`user_id`) REFERENCES `xf_user` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

CREATE TABLE `user_stat_overall` (
     `user_id` int(10) unsigned NOT NULL,
     `human` blob NOT NULL,
     `beast` blob NOT NULL,
     `total` blob NOT NULL,
     PRIMARY KEY (`user_id`),
     CONSTRAINT `user_overall` FOREIGN KEY (`user_id`) REFERENCES `xf_user` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

So I was thinking I could add a user_stat_rank table which would be user_id, stat_id, rank. Then say I want to get the first page of the ladder ordered by the ‘kills’ stat I could get all the user_ids order by rank where stat_id is kills. Then make a second query to populate all the users stats.

After writing all this out it seems like it would work fine but I might not be seeing something. I also understand this question is all over the place so if you would like me to edit in details at places just say so.

Answer 1

For sake of managibility, I would stick to adding a column for every stat. In the long run, this will probably be the easiest way to manage it without ending up in a corner due to the limitations that for instance the EAV model would impose on you.

If you’re worried about the stats table growing too large, you could consider implementing some form of table partitioning where you regularly move the data older than 4 weeks to (a) historic table(s). The historic table(s) can be indexed to the extreme, as they won’t require constant updating.