Хранение данных о больших системах в базе MySQL

[DeimoS]

Я, конечно, новичок в разработке модов и сам еще не делал инвентарь, но думаю, чтобы не создавать отдельную ячейку для каждого предмета в таблице игроков, сделал бы одну - с большим числом. А уже в моде предоставлял это число в двоичном виде и считывал наличие предмета по алгоритму вроде "номер цифры (степень двойки, если так удобнее) - id предмета, значение 1/0 - наличие/отсутствие соответственно". Так, при хранении числа 1234 получим следующее двоичное: 10011010010, что означает, что у игрока не имеются предметы с id 0,2,3,5,8,9(индексы нулей), имеются предметы с id 1,4,6,7,10 (индексы единиц. считаю с нуля, по-арабски, т.е. справа налево). А само соответствие "id-название" я вообще хранил бы только в самом моде в виде двухмерного массива.. Ну а зачем мне в бд хранить неизменяемые названия и каждый раз загружать их в мод, если я могу сразу в моде же их и сохранить как глобальную константу? Как сказал Павел Дуров (и далеко не только он), упрощайте.

Во-первых, MySQL не ограничивается только числовым типом столбцов. Для разных задач следует использовать разные типы, дабы упросить жизнь и себе, и самой MySQL. В твоём случае может пригодится тип SET. Или же можно битовыми операторами воспользоваться в запросах.

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

Не занимайтесь фигнёй и не изобретайте велосипеды, а просто создайте под каждый предмет свой столбец и всё. Это будет и быстро в плане выборки, и запросы будут компактными, и работа с данными будет удобной.

[Josan_Solomon]

Почему же, это будет достаточно легко. Не просто же так я именно к двоичной системе потянулся :)
Нужен конкретный предмет - получаем остаток от деления числа-представителя на двойку в степени, равной id предмета. То же самое с загрузкой Нагрузка ни капельки не увеличится, если вместо запроса "update `player_items` set `quantity_of_item_id_3` = '2' where `ownerid`='12'" использовать "update `accounts` set `items` = '12313' where `id` = '12'". Что касается экономии места, оно колоссальное, ведь таблицы предметов не будет вовсе, а будет только дополнительный столбец в таблице игроков с ячейкой, имеющей десятичное или двоичное (кому как удобно) представление числа-представителя.

Пожалуйста, скажите свое мнение об этом теперь, мне оно очень важно!

[DeimoS]

Почему же, это будет достаточно легко. Не просто же так я именно к двоичной системе потянулся :)
Нужен конкретный предмет - получаем остаток от деления числа-представителя на двойку в степени, равной id предмета. То же самое с загрузкой Нагрузка ни капельки не увеличится, если вместо запроса "update `player_items` set `quantity_of_item_id_3` = '2' where `ownerid`='12'" использовать "update `accounts` set `items` = '12313' where `id` = '12'".

Ну вот только проведи замеры сначала, прежде чем утверждать, то нагрузки не будет :)
А потом учти то, что запросы на обновление данных будут происходить каждый раз, когда количество предметов в инвентаре меняется. Заодно и учти вариант, когда тот или иной предмет будет удалён из инвентаря, из-за чего все твои значения просто станут неправильно работать и тебе придётся городить костыли ради того, чтоб всё исправить. А потом задай себе вопрос: ради чего столько страданий, если ты профита от этого существенного не получил?

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

Вся эта экономия будет напрочь обесценена, во-первых, потраченным временем на написание всей системы (нужно будет учесть гораздо больше факторов, если ты не хочешь ловить сбой при малейшем изменении порядка предметов), а, во-вторых, на затраченные время, которое уйдёт на обработку данных. Как я уже говорил, такой вариант запроса крайне недружелюбно будет работать в случае с более сложными выборками данных из таблицы (например, получить всех игроков, у которых есть 3 определённых предмета из 30-и доступных). И чем более сложные задачи ставить перед такой системой, тем больше будет подводных камней обнаруживаться.

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

[Josan_Solomon]

Хмм, хорошо.. Я в своем моде до инвентаря дойду еще совсем не скоро, а когда дойду - обязательно проверю))
Касательно выборки. А разве не разумнее выгружать все данные в мод, и уже оттуда делать выборку?

[DeimoS]

Касательно выборки. А разве не разумнее выгружать все данные в мод, и уже оттуда делать выборку?

Эмм, нет. MySQL заточена под работу с данными. Она написана на более функциональном языке (с/с++), который имеет более гибкую структуру, лучший компилятор и не имеет прослойки в виде виртуальной машины (да и много чего ещё). Это одна из причин, почему MySQL в большинстве случаев быстрее файлов, хотя, казалось бы, файлы всегда открываются локально и доступ к ним происходит быстрее, нежели MySQL, часть времени которой занимает пересылка данных.
При правильной структуре таблицы и при правильных запросах, MySQL практически всегда будет быстрее обрабатывать данные, нежели если это делать вручную.

Да и не стоит забывать, что, начиная с 39-ой версии, в плагине от BlueG есть мультипоточность, которая позволяет MySQL обрабатывать запрос и подготавливать результат параллельно серверному потоку. А это значит, что как долго MySQL не обрабатывала бы запрос, сам сервер этого не почувствует и сможет спокойно работать дальше (хотя стоит учитывать, что пока MySQL обрабатывает один запрос, она не может обработать другой. Поэтому все запросы, отправленные после запроса, который обрабатывается долго, так же будут задержаны).

[Josan_Solomon]

Нет, я имел ввиду не хранение в файлах наподобие mxini, а выгрузку из таблицы MySQL в мод всех данных при запуске сервера и подключении каждого игрока (ну, банальная выгрузка), а уже потом использовать данные непосредственно из глобальных переменных мода. Не обращаться же каждый раз к бд. И выборку тоже делать из уже "скачанных" из базы данных.

[Elrmrnt-Kritik]

Так здесь никто и не писал же, что следует работать с данными удаленно. В любом случае при загрузке аккаунта можно (и, наверное, нужно) загрузить все данные игрока и работать с ними. Но и обновлять следует сразу по мере обновления, а не все данные каждые n минут/секунд. Как раз запросы этих обновлений постоянно здесь и появляются.