Последний раз редактировалось Pa4enka; 27.11.2019 в 18:43.
Ну тогда в твоём случае, следует очищать при коннекте массив с данными инвентаря и, задавать например, значение, характеризующее, что данный слот не был загружен. И при добавлении данного итема, делать проверку на то, загружался ли данный итем или нет, и уже исходя из этого обновлять или же создавать строку.
База в данном случае хранит существующие(!) айтемы игроков. Всё остальное - пустые ячейки. Спрашивается, зачем они нужны в базе?
Ну так заполни все слоты, которых нет в базе, при регистрации нулями, к примеру, либо -1. Смотря как у тебя обозначаются пустые слоты. И не нужно будет ничего проверять, ибо у тебя всегда будет актуальная информация и на сервере и в базе.
Последний раз редактировалось Pa4enka; 27.11.2019 в 19:08.
А теперь сделай бэкап какой-нибудь своей заполненной таблицы (или скачай мод с бэкапом БД) и посмотри на структуру запросов :)
MySQL способна по несколько тысяч записей создавать за секунду без каких-либо трудностей. И это без какой-либо специфичной настройки под конкретное железо, что может увеличить скорость работы MySQL.
Так что нет, проблем от 30 запросов не будет :)
И да, я имею ввиду именно то, что в БД создаются записи для хранения предметов сразу при регистрации, а не по мере поступления данных. Просто потому что второй вариант будет требовать от тебя проверки существования этих самых данных: то бишь, каждое обновление какого-либо из слотов тебе нужно будет отправить сначала SELECT-запрос, а только потом отправить UPDATE или INSERT. Гораздо проще и надёжнее реализовать создание строк прямо при регистрации (и при авторизации так же проверять существование записей под каждый слот).
Стоит понимать две простых истины:
1) Вы тут не микропроцессоры программируете и у вас нет сильных ограничений по доступной для использования памяти. Так что нет никакого смысла экономить ей, урезая, при этом, скорость работы и надёжность системы (от которой напрямую зависит то, будете ли вы тратить время на создание новых систем или на исправление багов в уже написанных системах). UPD: И да, это применимо только в случае, когда память используется по делу :) Как, например, в нашем случае.
2) Размер такой таблицы даже с миллионом записей будет каким-то уж очень большим. А, при желании, можно прикрутить и перенос старых данных в дочернюю таблицу (либо их удаление). Хотя, опять же, непонятно на каких калькуляторах нужно запускать MySQL-сервер, чтоб размер столь простых таблиц смог создать хоть какие-то проблемы. MySQL наоборот создали для того, чтоб иметь возможность быстро работать с данными, тратя, при этом, дополнительную память (если уж совсем в дебри не зарываться, то индексы - отличный пример того, как жертвуя памятью мы можем получить существенный прирост к скорости, если сделаем всё правильно).
- - - Добавлено - - -
Ну и да: я бы всё же советовал использовать в данном случае вариант со столбцами под слоты и одной записью в таблице для одного игрока, а не "1 слот = 1 строка". Вариант с построчным заполнением хорош в системах, которые могут часто изменяться или сами по себе требуют гибкого количества записей (например, если вы решите сделать так, что за донат можно купить любое количество слотов, то да, вариант с "1 слот = 1 строка" - идеальный). В данном же случае гораздо проще и вам, и MySQL будет, если данные игрока будут хранится в одной строке.
Просто научитесь пользоваться оператором "ALTER TABLE" (или просто тупо делайте нужные изменения в таблице, а потом делайте её бэкап и смотрите какой код запросов вам сгенерирует phpMyAdmin) и тогда сможете сделать вариант с одной записью на игрока таким же гибким, как и вариант "1 слот = 1 строка".
Запрос на проверку существования столбца тоже выглядит просто:
SHOW COLUMS FROM `имя_таблицы` WHERE `Field` = 'имя столбца'
Без "WHERE", соответственно, выдаст просто структуру таблицы и можно будет проверить существование столбцов на стороне сервера (хотя можно и форматирование запроса сделать соответствующе, чтоб сама MySQL всё проверила и вернула лишь "1" или "0"). Собственно, проверяете существование столбцов и если каких-то не хватает (а так будет только если вы решите добавить новые столбцы) - добавляете их через "ALTER TABLE".
В общем, этот способ можно сделать столь же гибким, но он, при этом, будет гораздо экономичнее и проще. Вся основная нагрузка будет сконцентрирована только при старте сервера. А выгружать и обновлять придётся одну единственную строку во всех случаях. Соответственно, создав составной индекс на поля с AI и ID аккаунта вы получите хорошую производительность и, при этом, компактность (для инвентаря с 30 слотами такой вариант будет содержать на 58 записей меньше, ибо не нужно будет для каждого слота дублировать номер строки и ID аккаунта. То бишь: "(количество слотов - 1) * 2").
Последний раз редактировалось DeimoS; 28.11.2019 в 17:08.
Связаться со мной в VK можно через личные сообщения этой группы
Заказы не принимаю
Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
Великих идей полно, на них нет спроса.
Воплощение идеи в законченную игру требует долгой работы,
таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
Предложить идею просто, воплотить – вот в чём проблема
Steve Pavlina
execution (27.11.2019) Pa4enka (28.11.2019) SteveStage (28.11.2019)
1 вариант и был у меня изначально (только в бд с аккаунтами), а 2 вариант довольно интересный...
Я думал, что значения для каждого игрока будут в 1 строку со значениями, а тут на каждый слот своя строка в бд, вот этого варианта инвентаря я точно не учел
UPD: Я вернул все как было, только теперь у инвентаря своя таблица (вариант с столбцами под каждый слот), да и он в моде будет выглядеть проще (вместо постоянных sscanf и создания переменных под каждый предмет и количество в слоте, это будет храниться в энуме)
Последний раз редактировалось SteveStage; 28.11.2019 в 19:56.
Вопрос решён?
Связаться со мной в VK можно через личные сообщения этой группы
Заказы не принимаю
Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
Великих идей полно, на них нет спроса.
Воплощение идеи в законченную игру требует долгой работы,
таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
Предложить идею просто, воплотить – вот в чём проблема
Steve Pavlina
Да, спасибо за то, что не поленился и вынес все ключевые сообщения в отдельную тему.
Эту тему просматривают: 2 (пользователей: 0 , гостей: 2)