Оптимальная конструкция стола для системы ELO
< <Таблица эло отсортирована по полю Дата. Таблица имеет два поля данных об эло игрока.
Когда создается новая игра, вычисленные данные elo будут накапливаться в таблице напрямую. Это работает, когда игра является самой новой.
Elo Table
Date | 2022-04-01
Player A | 1015.0 (Win)
Player B | 985.0
Date | 2022-04-02
Player A | 1021.0 (Win)
Player B | 979.0
<--------------------+
// new game created |
// this data will be located at here ---+
Date | 2022-04-03
Player A | 1012.0
Player B | 988.0 (Win)
Однако, когда была создана прошлая игра, возникла не совсем привычная ситуация.
Во-первых, вычисляются данные elo с предыдущими данными для текущей игры. Во-вторых, все данные elo, которые следуют за этой игрой, будут обновлены.
Elo Table
Date | 2022-04-01
Player A | 1015.0 (Win)
Player B | 985.0
<-----------------------+
Date | 2022-04-03 |
Player A | 1021.0 (Win) (this value will be |
Player B | 979.0 re-calculated.) |
|
// past game created. |
// this data will be located at here --------+
// all data after this will be updated.
Date | 2022-04-02
Player A | 1002.0
Player B | 998.0 (Win)
Я не могу найти другого решения. Также я думаю, что это решение не идеально, потому что когда вы создаете прошлую игру, вы должны пересчитать массивные данные elo если у вас большая таблица.
- Is database can handle this? Won't it be slow?
- It could be make large queries. Is inevitable?
Есть ли какая-нибудь идея для управления системой ELO? Я видел это и это, но не могу найти другого решения.
Отделите хранение данных от обработки приложений.
Используйте таблицу для хранения данных. Не пытайтесь писать алгоритмы ELO на языке SQL.
Поскольку ELO довольно сложен, используйте прикладной язык для вычисления ELO. Просто перезагрузите необходимые строки (всю таблицу??), пересчитайте рейтинги, затем UPDATE или перестройте таблицу.