1

过去一年左右我一直在处理这个问题，改变我正在做的事情并尝试不同的事情。问题与模式有关，因此我仍然可以在玩家/氏族阶梯中很好地订购，但如果我们想稍后添加一个统计信息，它不会锁定我们的表格，因为每列一个统计信息会更改每一行。

我看到了如何做到这一点的两种选择，但似乎都不正确。一个是每列一个统计数据。将有 4 个表，user_stat_summary（用于梯子上显示的基本统计数据）、user_stat_beast（团队是人类与野兽）、user_stat_human 和 user_stat_overall。过去 30 天的统计数据随处可见。一项 cron 作业将通过查询 30 天之后发生的匹配并将这些统计信息从 3 个主表中取出并将它们放入整体表中来获取任何过时的统计信息。比赛将有每个球员在那场比赛中获得的统计数据。我在这里看到的问题是当我们有很多行时，如果说游戏发生了一点变化，我们就不能轻易地添加更多的统计数据。我在想的是每个表上的 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 是 kills 的排名获得所有 user_ids 顺序。然后进行第二次查询以填充所有用户统计信息。

在写完所有这些之后，它似乎可以正常工作，但我可能看不到任何东西。我也明白这个问题无处不在，所以如果您希望我在某些地方进行详细编辑，请说出来。

4

1 回答 1

1

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

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

于 2012-11-08T06:30:20.680 回答