Структура таблицы результатов игрока в SQL

Question

Мне нужно перенести таблицу результатов игры из (не смейтесь, пожалуйста ...) * .ini database в таблицы SQL, так как я хочу перенести всю игру на базу MySQL.

Требуется хранить оценки пользователей в базе данных, чтобы иметь возможность получить таблицы результатов для общего промежутка времени / год / месяц / неделя / день. Это занимает каждый год: {оценка за год} + {оценка за месяц} * 12 + {оценка за неделю} * 52 + {оценка за день} * 360 = ~ 425 строк на пользователя + 1 строка {общая оценка} на пользователя. Это не чувствует себя оптимизированным, поэтому я здесь с этим вопросом.

Какую базу использовать? Упомянутый выше, является базой для временных интервалов, используя такую ​​структуру:

{timespan type} {timespan} {user ID} {score for type 1} {score for type 1} {score for type 1} {score for type 2}

Еще одна вещь, которую я должен отметить. Существуют разные методы сортировки для разных типов оценок. Если первый тип - простой результат, где я беру наибольшее (больше - лучше), то второй тип - это скорость, где я сортирую по самой высокой скорости (меньше - лучше).

Если у вас есть вопрос: «Зачем разделять строки на недели / месяцы / годы / в целом?», То ответ таков: я хочу получить быстрый способ получить таблицу результатов, например, для счета последних недель типа 2, сначала 3 места.

Я думал, может быть, если я сохраню только {дневной счет}, избавлюсь от этих 426-360 = 66 строк на пользователя в текущей структуре, что приведет к новой структуре:

{user ID} {day number} {score for type 1} {score for type 1} {score for type 1} {score for type 2}

Как я выберусь "Первые 3 места за лучший результат в скорости на предыдущей неделе". Это займет несколько многоуровневых вычислений ...

1. Запрос для строк с днями, которые входят в промежуток времени за предыдущие недели для ВСЕХ пользователей
2. Суммируйте все оценки для каждого {идентификатора пользователя} или получите наименьшую оценку (в зависимости от типа оценки) и поместите в новую таблицу
3. Запрос новой таблицы, сортировка по столбцу оценки ASC или DESC (в зависимости от типа оценки) и получение первых 3 строк
4. Повторите шаги 2. и 3. для каждого столбца оценки

Если я хочу делать это более 1-3 раз в минуту (как после каждого нового ввода в таблице, мне нужно оценить, сколько очков конкретному пользователю нужно получить в более высоком положении, я полагаю, что это заняло бы некоторые серьезные серверные ресурсы. Что касается структуры, указанной в верхней части вопроса (база времени), то для каждого столбца оценки требуется только шаг 3.

Спасибо за ответы и предложения!

Текущий формат данных следующий:

Overall file: overall.ini
(in folder of yearnumber) Year file: 2011.ini
(in folder of yearnumber) Month files: m1.ini ... m12.ini
(in folder of yearnumber) Week files: n1.ini ... n52.ini
(in folder of yearnumber) Day files: m1d1.ini ... m12d1.ini

Данные хранятся внутри:

[~REZ~]
User13245325=1145 203.433 3 1.735
User3425435=1412 173.871 8 2
User32487854=18 76.253 1 11.016
User345645=2153 155.139 8 2.344
User65875=100 67.767 2 10.016
User453325=26 138.568 1 3.031

PS: Это общий вопрос, не связанный напрямую с разработкой игры, поэтому, пожалуйста, не выбрасывайте его в раздел разработки игр SO.

Answer 1

Честно говоря, я действительно изо всех сил пытаюсь понять, что вы спрашиваете здесь - но если я правильно понимаю, есть какая-то другая система, в которой записываются фактические результаты игры, и вы хотите превратить эти игровые данные в таблицу лидеров в стиле структуры данных, и вы хотите, чтобы ваши запросы выполнялись действительно очень быстро.

Итак, во-первых, кажется, вы беспокоитесь о размере ваших данных. Если вы не имеете дело с абсолютно астрономическими масштабами (Google, Facebook, Twitter), вам, вероятно, не нужно. Дисковое пространство дешево, и хорошо проиндексированная база данных так же быстро работает с миллионами строк, как и с десятками.

Вообще говоря, вам нужно решить, собираетесь ли вы торговать пространством (предварительно вычисляя результаты) для скорости, и когда вы собираетесь делать вычисления.

В целом, работа с «необработанными» данными и вычисление результатов во время выполнения является наиболее простой для понимания и обслуживания и имеет наименьший риск ошибок, но также, вероятно, будет самым медленным. Тем не менее, с этого я и начну. Вы не указываете, как хранятся ваши «сырые» данные или как часто они обновляются, но я бы начал с написания запроса, который выдает ваши предполагаемые данные. Если это сложно, я бы разделил некоторые промежуточные шаги на представления, чтобы упростить запрос.

Затем я бы измерил производительность, используя инструмент нагрузочного тестирования (JMeter или аналогичный идеально).

Если - но только если - это действительно слишком медленно, я бы начал с постепенного превращения представлений в предварительно вычисленные таблицы, с введения регулярных пакетных заданий для заполнения этих представлений. Это полностью зависит от ваших данных и того, насколько «устаревшими» они могут быть.

При таком подходе обычно можно получить очень хороший прирост производительности - и решение остается довольно простым и устойчивым к ошибкам, пока выполняются пакетные задания ...

Только когда этот подход наталкивается на узкие места в производительности, я бы рассмотрел возможность предварительного вычисления всего набора данных. В этом случае вы также можете создать таблицу, точно такую ​​же, как та, которую вы хотите вывести на экран.

Answer 2

Я предлагаю 2 таблицы.

пользователя, со связанной информацией о пользователе, и счет с информацией о счете.

оценка будет выглядеть так:можно легко сделать с помощью запроса.