Вид для печати
Доброе время суток. Работая над системами оружия и инвентаря, столкнулся с трудностями в хранении информации и работы с ней. Для первой системы нужно порядка 20 столбцов, а для второй порядка 40. Не думаю, что разумно все 40 столбцов добавлять в одну таблицу. Подумывал об использовании типа данных SET в MySQL. Но через него получится хранить лишь именование оружия/предмета (идентификатор). А их количество - нет. Может посоветуете что-нибудь?
Создай отдельную таблицу inventory и оттуда просто выгружай информацию о объектах
Количество предметов большое и хранить типа item1, item2, item3... не думаю, что есть правильно. Ведь наверняка есть какие-то нормальные способы. Может стоило и на форумах по MySQL спросить, но и здесь заметил ziggi, Deimos, вроде VVWVV с базами данных хорошо работают и понимают, где, что и как лучше.
создаешь просто один столбец "items" (к примеру) с ид предметов через запятую и выгружаешь с помощью sscanf через :blush2:Цитата:
Сообщение от Elrmrnt-Kritik
Во многих планах убогий способ. Прежде всего потому, что для обновления одного значения придется вновь форматировать весь лист.
Покажи, что ты хочешь сделать.
А что показывать-то?) Есть список предметов, идентификаторы которых объявлены в enum. Вроде такого:
Соответственно, в переменной gPlayerItem[playerid][предмет] указано количество предметов. Но типов предметов достаточно много и не хотелось бы создавать под них 40 столбцов (и работать будет с ними неудобно). А метод с созданием строки, куда уже записывать все предметы по порядку, считаю убогим :pardon:
Немного хотелось бы дополнить.
Была идея создать две таблицы: в одной таблице список предметов в формате "itemid | itemname ", а в другой три столбца в формате "accountid | itemid | itemcount". Таким образом, если у игрока есть предмет 1 (секундомер) в количестве 2шт. и предмет 3 (телефон) в количестве 5 штук, во второй таблице будет две записи:
accountid itemid itemcount 1 1 1 1 3 5
А первая таблица примет следующий вид:
itemid itemname 1 секундомер 3 телефон
(выделенное кирпичным цветом стоит связать). Но в данном методе я тоже вижу минус, ибо на одного игрока придется 40 записей (максимум). Тоже не совсем экономно. Но по крайней мере оперировать будет проще :scratch_one-s_head:
Поздравляю, ты изобрёл нормализацию :). Так и делай.Цитата:
Сообщение от Elrmrnt-Kritik
У меня инвентарь так выглядит:
https://i.imgur.com/erb8SKU.png
Если не секрет, а название предметов и в моде, и в базе данных хранятся? Со стороны удобства хорошо бы везде хранить, но... Экономить нужно везде, тем более в наше время :blush2:
Если я тебя правильно понял, то почему просто не сделать подобную структуру?
Ну и база будет выглядеть примерно так:PHP код:#define MAX_PLAYER_ITEMS 40 // к примеру
enum e_PLAYER_ITEM
{
item_id,
item_count
};
new
gPlayerItems[MAX_PLAYERS][MAX_PLAYER_ITEMS][e_PLAYER_ITEM];
// При загрузке аккаунта
{
new
sql_query[49 - 2 + MAX_PLAYER_NAME];
format(sql_query, sizeof(sql_query), "SELECT * FROM `players_items` WHERE `name` = '%s'", /*NickName*/); // Или же используй UID, ну или что тебе там удобно.
mysql_tquery(/*ID подключения к mysql*/, sql_query, "UplodPlayerItems", "d", playerid);
}
forward UplodPlayerItems(playerid);
public UplodPlayerItems(playerid)
{
new
rows;
cache_get_row_count(rows);
if(rows > 0)
{
for(new i = 0; i < rows; i++)
{
cache_get_value_name_int(i, "item_id", gPlayerItems[playerid][i][item_id]);
cache_get_value_name_int(i, "item_count", gPlayerItems[playerid][i][item_count]);
}
}
return 1;
}
https://i.imgur.com/0G0dtD5.png
- - - Добавлено - - -
А к чему хранить названия в базе данных? Ты, в любом случае, используешь эти данные на стороне сервера.Цитата:
Сообщение от Elrmrnt-Kritik
Ну, кто его знает, вдруг мне понадобится изменять через базу данных (хотя я стремлюсь к динамичности и стараюсь делать возможность изменять большинство параметров через игру). А так спасибо большое за то, что тоже уделили внимание)
Экономить что?Цитата:
Сообщение от Elrmrnt-Kritik
Память :) Ну, ведь больше будет весить база, если хранить там больше данных.
А ты упёрся в потолок использования памяти? Сколько на данный момент весит твоя БД? Да и разница будет минимальна.Цитата:
Сообщение от Elrmrnt-Kritik
Да, пожалуй, ты прав, не буду дотошным :mosking:
Хочется дополнить то, что 40 столбцов в одной таблице - это не очень много :) Лимит для одной таблицы - 4096 столбцов, хоть это и не значит, что всегда стоит пытаться уместить всё в одну таблицу. Вот тут можешь про это почитать - https://dev.mysql.com/doc/refman/5.6...unt-limit.html
И да, "проблема" того варианта, что был выбран выше, не в том, что таблица будет занимать больше места (разница, как уже заметили, будет не столь большой), а в том, что выборка будет происходить медленнее, если составлять запросы неправильно, так как строк в таблице будет много. Все запросы должны сопровождаться оператором LIMIT, дабы MySQL не продолжала обрабатывать всю таблицу, найдя нужные n строк, которые были где-то в начале.
Ну и желательно продумать систему фильтрации устаревших данных, например, помещая их в отдельную таблицу (то же стоит и с аккаунтами делать), дабы таблица не состояла из нескольких миллионов строк через пару месяцев работы сервера, где больше половины строк будут от аккаунтов, которые уже давно не появлялись в сети.
Собственно я проблему разглядел больше в том, что для загрузки аккаунта будет огромный запрос. Ведь работать с запросом, длина которого больше 300 символов, тоже неудобно. И по большому счету, если следовать нормализации, то все запросы будут крайне большие. Из-за чего у меня возникает вопрос, есть ли логично все запросы вынести куда-нибудь отдельно?
Во-первых, если нормально оформлять запрос (переносы в помощь), то никаких проблем с его длинной не будет. Не говоря уже о том, что можно прибегнуть к помещению запроса в файл и прочим хитростям, позволяющим убрать длинный запрос из скрипта.Цитата:
Сообщение от Elrmrnt-Kritik
Во-вторых, то, что во втором варианте запрос будет короче, лучше, максимум, только для тебя. Как я уже говорил, MySQL наоборот придётся делать более обширную выборку, ища среди кучи строк не какую-то одну, а несколько. И вот это действительно может сказаться на производительности, нежели длинный запрос или 40 столбцов в одной строке.
В-третьих, о каком длинном запросе идёт речь? Тебе ведь не нужно каждый столбец в отдельности указывать - для этого есть символ "*", который укажет на то, что нужно выгрузить все столбцы.
Я, конечно, новичок в разработке модов и сам еще не делал инвентарь, но думаю, чтобы не создавать отдельную ячейку для каждого предмета в таблице игроков, сделал бы одну - с большим числом. А уже в моде предоставлял это число в двоичном виде и считывал наличие предмета по алгоритму вроде "номер цифры (степень двойки, если так удобнее) - 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'". Что касается экономии места, оно колоссальное, ведь таблицы предметов не будет вовсе, а будет только дополнительный столбец в таблице игроков с ячейкой, имеющей десятичное или двоичное (кому как удобно) представление числа-представителя.
Пожалуйста, скажите свое мнение об этом теперь, мне оно очень важно!
Ну вот только проведи замеры сначала, прежде чем утверждать, то нагрузки не будет :)Цитата:
Сообщение от Josan_Solomon
А потом учти то, что запросы на обновление данных будут происходить каждый раз, когда количество предметов в инвентаре меняется. Заодно и учти вариант, когда тот или иной предмет будет удалён из инвентаря, из-за чего все твои значения просто станут неправильно работать и тебе придётся городить костыли ради того, чтоб всё исправить. А потом задай себе вопрос: ради чего столько страданий, если ты профита от этого существенного не получил?
Вся эта экономия будет напрочь обесценена, во-первых, потраченным временем на написание всей системы (нужно будет учесть гораздо больше факторов, если ты не хочешь ловить сбой при малейшем изменении порядка предметов), а, во-вторых, на затраченные время, которое уйдёт на обработку данных. Как я уже говорил, такой вариант запроса крайне недружелюбно будет работать в случае с более сложными выборками данных из таблицы (например, получить всех игроков, у которых есть 3 определённых предмета из 30-и доступных). И чем более сложные задачи ставить перед такой системой, тем больше будет подводных камней обнаруживаться.Цитата:
Сообщение от Josan_Solomon
MySQL создана для работы с большими объёмами данных. И те же нормализации, о которых говорилось выше, придуманы для того, чтоб сформировать такую структуру таблицы, при которой доступ к конкретным данными будет максимально быстр и удобен. А твой метод - это шаг назад, а не полезное решение. С таким же успехом можно просто с файлами работать, получая даже большие показатели по скорости, если база данных находится не на локальном сервере (не на той же машине, на которой стоит игровой сервер).
Хмм, хорошо.. Я в своем моде до инвентаря дойду еще совсем не скоро, а когда дойду - обязательно проверю))
Касательно выборки. А разве не разумнее выгружать все данные в мод, и уже оттуда делать выборку?
Эмм, нет. MySQL заточена под работу с данными. Она написана на более функциональном языке (с/с++), который имеет более гибкую структуру, лучший компилятор и не имеет прослойки в виде виртуальной машины (да и много чего ещё). Это одна из причин, почему MySQL в большинстве случаев быстрее файлов, хотя, казалось бы, файлы всегда открываются локально и доступ к ним происходит быстрее, нежели MySQL, часть времени которой занимает пересылка данных.Цитата:
Сообщение от Josan_Solomon
При правильной структуре таблицы и при правильных запросах, MySQL практически всегда будет быстрее обрабатывать данные, нежели если это делать вручную.
Да и не стоит забывать, что, начиная с 39-ой версии, в плагине от BlueG есть мультипоточность, которая позволяет MySQL обрабатывать запрос и подготавливать результат параллельно серверному потоку. А это значит, что как долго MySQL не обрабатывала бы запрос, сам сервер этого не почувствует и сможет спокойно работать дальше (хотя стоит учитывать, что пока MySQL обрабатывает один запрос, она не может обработать другой. Поэтому все запросы, отправленные после запроса, который обрабатывается долго, так же будут задержаны).
Нет, я имел ввиду не хранение в файлах наподобие mxini, а выгрузку из таблицы MySQL в мод всех данных при запуске сервера и подключении каждого игрока (ну, банальная выгрузка), а уже потом использовать данные непосредственно из глобальных переменных мода. Не обращаться же каждый раз к бд. И выборку тоже делать из уже "скачанных" из базы данных.
Так здесь никто и не писал же, что следует работать с данными удаленно. В любом случае при загрузке аккаунта можно (и, наверное, нужно) загрузить все данные игрока и работать с ними. Но и обновлять следует сразу по мере обновления, а не все данные каждые n минут/секунд. Как раз запросы этих обновлений постоянно здесь и появляются.