Question

过去一年左右我一直在讨论这个问题，改变我正在做的事情并尝试不同的事情。问题是与模式有关，所以我仍然可以很好地在播放器/部落阶梯中排序，但是如果我们想要稍后添加一个统计数据，它将不会锁定我们的表，因为每列有一个统计数据而改变每一行。

我看到两种方法可以做到这一点，但两者似乎都不对。一列是每列一个统计数据。将有4个表，user_stat_summary（用于梯子上显示的基本统计数据），user_stat_beast（团队是人类与野兽），user_stat_human和user_stat_overall。统计数据显示在过去30天内的任何地方。一个cron作业将通过查询30天后发生的匹配并从3个主表中删除这些统计数据并将它们放入整个表中来获取任何过时的统计数据。比赛将为每位球员获得该比赛的统计数据提供blob。我在这里看到的问题是，当我们有很多行时，我们不能轻易添加更多的统计数据，当说游戏稍微改变时。我在想的是每张桌子上的extra_stats blob列，如果我们添加新的统计数据，他们根本就不会对梯子进行排序。

另一种选择是EAV模型，这是我一直在玩的但似乎无法正确使用它。我会在每个查询中获得更多的行，然后将它们分组到用户中，并且顺序在大多数情况下都可以工作但是由于通常选择了未知数量的行，因此我无法获得分页限制。

我在想的是EAV模型，其中有一个表格，用于存储可用于订购的每个统计数据的排名。所以EAV表目前如下......

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

所以我想我可以添加一个user_stat_rank表，即user_id，stat_id，rank。然后说我想得到'kills'统计所订购的梯子的第一页我可以按stat_id杀死的等级获得所有user_ids顺序。然后进行第二次查询以填充所有用户统计信息。

写完所有这些后，似乎它会正常工作，但我可能没有看到任何东西。我也明白这个问题到处都是，所以如果你希望我在这些地方详细编辑，那么就这么说了。

Answer 1

为了管理，我会坚持为每个统计数据添加一列。从长远来看，由于例如EAV模型会对您施加的限制，这可能是最简单的方法来管理它而不会陷入困境。

如果您担心统计信息表变得过大，您可以考虑实施某种形式的表分区，您可以定期将超过4周的数据移动到（a）历史表中。历史表可以索引到极端，因为它们不需要不断更新。

如何构建我的数据库以进行游戏统计跟踪？

1 个答案: