// DeimoS: Первая часть темы находится тут: [Вопрос] Грамотное использование switch и if
Почему все говорят, что лучше искать по id, а не по нику?) Не понимаю, ведь id меняются, а ник нет
Вид для печати
// DeimoS: Первая часть темы находится тут: [Вопрос] Грамотное использование switch и if
Почему все говорят, что лучше искать по id, а не по нику?) Не понимаю, ведь id меняются, а ник нет
Эмм, так речь о ID аккаунта, а не о ID игрока на сервере... Номер строки, который генерирует AI-поле.
Собственно, про то, как хранить данные в моде, тебе описали выше. При желании, всё можно реализовать так, что и столбец для хранения нового предмета будет создаваться автоматически, если его не было. Либо можно хранить каждый предмет игрока в отдельной строке - тут зависит от того, какой метод нормализации таблицы выбирать.
То, что ты делаешь - крайне топорный метод, который занимает много места (а значит такой код сложнее обсуживать) и который требует кучу лишних телодвижений в случае добавления нового объекта. Но, опять же, тот метод, о котором я говорю, может быть довольно сложным без опыта и понимания того, что ты делаешь. Поэтому я бы советовал тебе пока оставить всё как есть, если оно работает, и заниматься реализацией других систем. С текущим уровнем знаний ты потратишь гораздо больше времени на переработку и решение проблем, нежели получишь профита от этого. Я эту тему озвучивал сугубо чтоб ты понимал, что можно лучше.
Еще раз, в бд есть столбцы slot, item и amount. А как хранить в item айди всех 3 предметов в 3 слотах? Как говорил Pa4enka, через "|"?
Допустим, но тогда столбец slot в таблице не имеет смысла, ибо предметы/их количество хранятся в столбцах item/amount, а slot в бд просто не нужен.
Согласен, но так и познаются нюансы Pawn, на практике. Если я не начну использовать то, про что я хочу узнать подробности - я никогда этого не узнаю, ибо я не изучаю то, что не планирую использовать, такой вот я, что поделать)
Но я все таки решил попробовать сделать инвентарь с загрузкой из бд, ибо:
1. Нет идей для других систем (не баянистых)
2. Я намерен сделать эту систему максимально близкой к идеалу, на сколько у меня это может получиться
Не знаю какая у тебя система инвентаря, но, лично у меня на сервере система такая, что у игрока может быть 20 предметов, у игрока еще может быть рюкзак так же на 20 предметов, инвентарь тачки/дома так же по 20 предметов. И чтобы не хранить огромное кол-во ненужных столбцов/переменных у меня под каждый слот id итема|количество и всё спокойно работает.
Так делать категорически не стоит. Вообще забудь о таком варианте хранения данных в MySQL. Это лишь усложняет работу с данными и, как следствие, замедляет получение результата.
Можно сделать либо так:
http://pro-pawn.ru/showthread.php?15...ll=1#post84550
Либо для каждого слота создавать 2 столбца для отдельного хранения item и amount.
В первом варианте для быстрой работы запросов следует разобраться с тем, что такое индексирование и создать индексы либо только на столбце и ID аккаунта, либо ID аккаунта + слот (в зависимости от того, как взаимодействовать с таблицей будешь запросами).
Во втором варианте, собственно, тоже желательно индексы создать, но там это будет чуть менее критично.
Оба варианта имеют право на жизнь.
Ну так и познавай. Только в реализации других систем. Система инвентаря у тебя, как я понимаю, уже работает. Так зачем тратить время на её переработку, если можно заняться реализацией других своих идей, всё так же продолжая изучать язык, но, при этом, не топчась на месте в плане разработки.
Выбор твой, но я бы тебе советовал просто намотать на ус информацию о том, что можно лучше, и, при желании, вернулся к переработке инвентаря потом: когда появится опыт и свободное время/желание. Просто потому что все эти изменения не сказать чтобы существенны (такой код лучше, но, в идеале, его следовало писать изначально таким, понимая что ты делаешь. Вручную подгонять существующий код под новый для тебя "стиль" - это большие риски допустить ошибки и сделать только хуже). Да и когда ты создаёшь какую-то новую систему, видя результат в игре, а не где-то в сознании понимая, что ты, возможно, сделал код лучше - это гораздо сильнее стимулирует тебя к разработке и изучению нового. Так работает психология человеческая :) Впрочем, как писал - выбор твой.
Так а зачем тебе обязательно уникальные системы писать? Ты реализуй хотя бы минимальный игровой базис для своего мода, чтоб его хоть завтра можно было запустить, показать игрокам и им, при этом, было бы интересно играть. И после этого уже можно заниматься всякой оптимизацией, если идей для дальнейшего развития нет.
Поверь: как бы ты хорошо сейчас не пытался код писать, через пол года активного изучения языка на большую часть своего старого кода ты без фейспалма смотреть не сможешь :) И это будет совершенно нормально (точнее, хорошо, ибо это прямой показатель того, что за пол года ты стал понимать язык лучше. Вот если у тебя такого чувства нет и ты, при этом, не чувствуешь, что можешь реализовать всё, на что только способен язык - это знак того, что ты стагнируешь и стоит что-то в своей жизни менять).
В том и беда, что каких-то конкретных статей тут не посоветовать. Всё нужно в частном порядке гуглить и, вероятнее всего, собирать информацию сразу с нескольких сайтов по одной теме (тут всё зависит от индивидуальной способности к обучению).
Отдельную. Желательнее, вообще создавать отдельные темы для отдельных вопросов или групп вопросов, если те на схожую тему. Так, чтоб можно было дать говорящее название для темы и упростить тем самым жизнь новичкам, которые могут наткнуться на твои темы и найти для себя ответы на какие-то свои вопросы. Или чтоб можно было удобно потом сослаться на ответ к твоей теме (как, собственно, я делал выше с другими темами) и человеку не пришлось вычленять из десятка подпунктов (то бишь, не нужно перегружать одну тему вопросами) тот, который ему нужен. Правила по поводу оформления тем ведь существуют не потому что администраторам так захотелось, а как раз чтоб упростить навигацию по форуму и поиск ответов =) Соответственно, думай в том же ключе и не прогадаешь.
Я предполагал, что это будет плохим примером ;)
Подобное оформления кода(|) не только затрудняет читаемость, но и взаимодействия с данными, которые там хранятся. Особенно придется в некотором роде "костылить" в коде сохранения, дабы обновить конкретный ид в конкретном слоте. На практике, имея набор цифр в столбце базы данных, не всегда можно сразу понять, что хотел сказать автор и что он там записывает. Особенно если в дальнейшем обвязывать мод с сайтом(админ панелью) для веб-разработчика будет проблемой без вас понять логику системы того же инвентаря. А имея отдельную таблицу с нормальной формой достаточно будет сделать выборку, вынести нужные нам данные со столбца и показать это в игре/сайте. Это действительно намного удобнее.
Если кратко:
1) При добавлении айтема -> insert into
2) При удаления айтема - удаления записи по иду слота с базы.
3) При редактировании - апдейт слота.
4) При передачи айтема другому игроку - апдейт ownerid на id "принимающего" игрока.
И так далее.
Но если ты пока не можешь понять о чем речь, то лучше оставить все как есть и довести систему до идеала в следующий раз. Как говорилось выше: в этом нет ничего плохого. Лично мне понадобилось приличное количество времени, дабы понять основы этого способа проектирования БД и несколько реализованных систем с помощью одной из нормальных форм.
В целом, это и есть описание одного из вариантов, что я выше кидал, но я бы тут избавился от удаления и просто обнулял строку в БД.
Чтоб:
1) Как можно дольше не иметь проблем с "переполнением" AI-поля (если поле будет иметь тип INT, то максимальное значение для поля будет "2147483647". Можно, конечно, сделать тип поля BIGINT, чтоб лимит стал "9223372036854775807", но с таким числом не получится работать на сервере, да и гораздо проще реализовать всё без пересоздания записей для слотов). Конечно даже лимит в "2147483647" довольно непросто достичь, но лучше сразу писать надёжный код, чем потом тратить время на восстановление его работоспособности.
2) Это позволит создавать записи для слотов при регистрации/авторизации и сразу загружать номера строк на сервер, чтоб впоследствии обновлять данные по этим номерам (ID), а не по ID аккаунта и номеру строки. Запросы будут короче и проще для MySQL.
Кхм, интересная теория, но я не сталкивался с таким большим AI. Но если такие случае имели место быть, то действительно стоит обратить внимания на обнуления строки, правда тогда будет немного не привычно видеть много null-записей в таблице. Плюс, размер таблицы прибавится, верно?
Имхо, это уже аспекты из ряда фантастики.
https://habr.com/ru/post/156489/
Как пример реального описания проблем, которые могут возникнуть в этом случае :)
Эмм, создаёшь столбец с флагом NOT NULL и таблица трактует все NULL значения как 0. В итоге вместо NULL/пустых записей будешь видеть нули :) И то только в последних двух столбцах: ID предмета и количество. Слот и ID аккаунта нулями не будут.
Если критичен размер таблицы, то стоит вместо создания отдельной записи под каждый слот создавать столбцы =) Тогда инвентарь одного игрока будет умещаться в одну запись. О чём я, собственно, писал ранее.
Автоматизировать подобный вариант можно точно так же, как и вариант с созданием отдельной строки под каждый слот.
А вообще особой разницы в размере не будет. По крайней мере она точно будет несущественной в сравнении со всеми плюсами.
DeimoS, пользуясь случаем, хотел уточнить. Если использовать 1 вариант (создание строки под каждый итем), следовательно при регистрации создавать столько строк, столько количество может быть итемов. Но это ж может быть до 30 INSERT запросов, не затратно ли? Или же есть более продуктивный способ?