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

[whale]

Если я тебя правильно понял, то почему просто не сделать подобную структуру?

#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; 
}  

Ну и база будет выглядеть примерно так:


- - - Добавлено - - -

Если не секрет, а название предметов и в моде, и в базе данных хранятся? Со стороны удобства хорошо бы везде хранить, но... Экономить нужно везде, тем более в наше время

А к чему хранить названия в базе данных? Ты, в любом случае, используешь эти данные на стороне сервера.

[Elrmrnt-Kritik]

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

[ziggi]

Если не секрет, а название предметов и в моде, и в базе данных хранятся? Со стороны удобства хорошо бы везде хранить, но... Экономить нужно везде, тем более в наше время

Экономить что?

[Elrmrnt-Kritik]

Память :) Ну, ведь больше будет весить база, если хранить там больше данных.

[ziggi]

Память :) Ну, ведь больше будет весить база, если хранить там больше данных.

А ты упёрся в потолок использования памяти? Сколько на данный момент весит твоя БД? Да и разница будет минимальна.

[Elrmrnt-Kritik]

Да, пожалуй, ты прав, не буду дотошным

[DeimoS]

Хочется дополнить то, что 40 столбцов в одной таблице - это не очень много :) Лимит для одной таблицы - 4096 столбцов, хоть это и не значит, что всегда стоит пытаться уместить всё в одну таблицу. Вот тут можешь про это почитать - https://dev.mysql.com/doc/refman/5.6...unt-limit.html

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

[Elrmrnt-Kritik]

Собственно я проблему разглядел больше в том, что для загрузки аккаунта будет огромный запрос. Ведь работать с запросом, длина которого больше 300 символов, тоже неудобно. И по большому счету, если следовать нормализации, то все запросы будут крайне большие. Из-за чего у меня возникает вопрос, есть ли логично все запросы вынести куда-нибудь отдельно?

[DeimoS]

Собственно я проблему разглядел больше в том, что для загрузки аккаунта будет огромный запрос. Ведь работать с запросом, длина которого больше 300 символов, тоже неудобно. И по большому счету, если следовать нормализации, то все запросы будут крайне большие. Из-за чего у меня возникает вопрос, есть ли логично все запросы вынести куда-нибудь отдельно?

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

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

В-третьих, о каком длинном запросе идёт речь? Тебе ведь не нужно каждый столбец в отдельности указывать - для этого есть символ "*", который укажет на то, что нужно выгрузить все столбцы.

[Josan_Solomon]

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