如何構建我的數據庫以進行游戲統計信息跟蹤？

Question

在過去的一年左右的時間里，我一直在討論這個問題，改變了我在做的事情，嘗試了不同的事情。 問題與模式有關，因此我仍然可以在玩家/公會梯子中很好地排序，但是如果以后要添加一個統計信息，則由於每一列有一個統計信息，它不會鎖定更改每一行的表。

我看到了兩種選擇方法，但這兩種方法似乎都不對。 一是每列一個統計信息。 將有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，等級。 然后說我想獲得按'kills'stat排序的階梯的第一頁，我可以按stat_id是kills的等級獲得所有user_ids順序。 然后進行第二次查詢以填充所有用戶統計信息。

在寫完所有這些之后，似乎可以正常工作，但是我可能看不到任何東西。 我也知道這個問題無處不在，所以如果您想讓我在各個地方進行詳細編輯，就這么說。

Answer 1

為了便於管理，我會堅持為每個統計信息添加一列。 從長遠來看，由於諸如EAV模型會強加於您的局限性，這可能是最簡單的管理方法而不會陷入困境。

如果您擔心stats表過大，則可以考慮實施某種形式的表分區，在該表分區中，您將定期將超過4周的數據移動到歷史表中。 由於不需要不斷更新，因此歷史表可以建立索引。