|
Реализация инветнаря
| |
| Quieteroks | Дата: Понедельник, 29 Апреля 2013, 23:46 | Сообщение # 1 |
частый гость
Сейчас нет на сайте
| Здравствуйте.
Имеется таблица Инвентаря (item) и поскольку инвентарь штука капризная, то таблица с автоинкриментом может быстро закончиться, т.е. превысить свой лимит по int полю. В связи с чем, хочу от него отказаться. И тогда будет новая проблема, в запросе будет по 3-4 ключевых поля, которые смогут как либо гарантировать нахождение конкретного предмета в базе.
Структура такая:
guid | itemid | slot | baglot | icount
guid - ID пользователя
itemid - ID премета
slot - место в инвентаре (0 - сумка, 1 - штаны и т.д.)
baglot - слот в сумке
icount - количество предметов
Для чего слот в сумке? Дабы позволить игрокам сортировать предметы и разбивать/собирать пачки. Соответственно имеется ограничение на количество предметов в одном слоте.
Выборка всей сумки достаточно простая, нужны только guid и slot = 0.
А вот как тогда обновлять?
Нужны как минимум 3-4 поля для опознания строки...
Подскажите, может какие то индексы составные прикрутить?
Какие есть варианты с такой реализацией структуры?
З.Ы. bigint не предлагать...
Если вам все равно где вы находитесь, значит вы еще не заблудились.
|
|
|
| |
| Tiendil | Дата: Вторник, 30 Апреля 2013, 10:41 | Сообщение # 2 |
участник
Сейчас нет на сайте
| Цитата А вот как тогда обновлять?
Не совсем понял, что обновлять?
Цитата З.Ы. bigint не предлагать...
Почему? Если в вопросе без объяснения встречается «не предлагайте это», значит в нём перечислены не все аспекты проблемы.
Участвовал в разработке Order of War (C++ UI & логика) и WoT (Python портал worldoftanks.ru почти всё :-) )
Текущий проект: the-tale.org - indie mmozpg
|
|
|
| |
| Quieteroks | Дата: Вторник, 30 Апреля 2013, 11:33 | Сообщение # 3 |
|
частый гость
Сейчас нет на сайте
| Tiendil, обновлять строку. Ведь предмет могут перемещать по сумке, могут использовать его (все в слоте или только один из), могут одеть, что повлечет перенос из сумки в экипировку, хоть и в одной таблице.
Цитата (Tiendil) Почему? Если в вопросе без объяснения встречается «не предлагайте это», значит в нём перечислены не все аспекты проблемы.
Bigint этот тот же инт, только больше вмешает значений, а проблема остается. Проблема в ограниченности количества строк (пускай даже через пару лет или больше).
Поскольку игрок будет собирать лут и после продавать его, то вероятно достаточно быстро лимит может быть исчерпан.
Если вам все равно где вы находитесь, значит вы еще не заблудились.
|
|
|
| |
| lvovand | Дата: Вторник, 30 Апреля 2013, 12:07 | Сообщение # 4 |
|
старожил
Сейчас нет на сайте
| INT(20) сделать и хватит инкрементов на долгое-долгое время,
а потом userid и itemid разве не определяют строку?
Разработка и продвижение сайтов. Дизайн
|
|
|
| |
| Quieteroks | Дата: Вторник, 30 Апреля 2013, 13:33 | Сообщение # 5 |
|
частый гость
Сейчас нет на сайте
| lvovand, в том то и дело, что не определяют. Не буду же я запрещать игрокам иметь одинаковые предметы в инвентаре.
На каждый слот сумки будет конкретное количество одинаковых предметов, при превышении, открывается еще один слот.
Я думал что guid (userid) и bagslot могут как то это гарантировать для сумки, а у экипировки этот показатель слота нужно будет отслеживать и удалять ячейку с слотом.
А для экипировки возможно будут гарантировать guid (userid) и slot, и контролировать, что бы не было одинаковых слотов в экипировке.
Но тогда я не совсем понимаю, как реализовать индексы. Нужно тогда два составных индекса, которые будут иметь отношение к одному и тому же полю одновременно.
Хотя может я недопонимаю некоторые аспекты работы базы данных...
Если вам все равно где вы находитесь, значит вы еще не заблудились.
|
|
|
| |
| lvovand | Дата: Вторник, 30 Апреля 2013, 15:29 | Сообщение # 6 |
|
старожил
Сейчас нет на сайте
| так и что если и одинаковые
вот юзер id 100 и id предмета 200
ставить limit 1,
и при поиске и при обновлении указать id 100 и id предмета 200 и limit 1
обновится одна строка и все, вторая у игрока останется незатронутой
Разработка и продвижение сайтов. Дизайн
|
|
|
| |
| Tiendil | Дата: Вторник, 30 Апреля 2013, 15:52 | Сообщение # 7 |
|
участник
Сейчас нет на сайте
| Цитата (Quieteroks) Проблема в ограниченности количества строк (пускай даже через пару лет или больше)
Скорее пары десятков тысяч лет. Если даже 2^32 идентификаторов будет расходоваться за месяц, то на исчерпание бигинт понадобится 2^32 масяцев.
Участвовал в разработке Order of War (C++ UI & логика) и WoT (Python портал worldoftanks.ru почти всё :-) )
Текущий проект: the-tale.org - indie mmozpg
|
|
|
| |
| Quieteroks | Дата: Вторник, 30 Апреля 2013, 18:08 | Сообщение # 8 |
|
частый гость
Сейчас нет на сайте
| lvovand,
Цитата (lvovand) и при поиске и при обновлении указать id 100 и id предмета 200 и limit 1
обновится одна строка и все, вторая у игрока останется незатронутой
Это самое оригинальное предложение на данный момент. Интересно, что будет в данном случае, если первой строчкой будет предмет, где уже лимит предметов, а во второй именно то, что требовалось обновить? limit 1, 1? А как тогда определить какая она в списке из трех одинаковых предметов? Влиять на физическое расположения строки не вариант. Можно еще order by добавить по количеству предметов. Но тогда Пользователь не сможет сортировать и разбивать на пачки.
Tiendil,
Цитата (Tiendil) Скорее пары десятков тысяч лет
А что если где то будет номер строки (как элемент массива) интоватся? Тогда же более 4миллиардной строке будет потеря правильного номера... Поскольку нет такого типа данных, как bigint в PHP.
Если вам все равно где вы находитесь, значит вы еще не заблудились.
|
|
|
| |
| lvovand | Дата: Вторник, 30 Апреля 2013, 18:37 | Сообщение # 9 |
|
старожил
Сейчас нет на сайте
| Цитата (Quieteroks) Интересно, что будет в данном случае, если первой строчкой будет предмет, где уже лимит предметов, а во второй именно то, что требовалось обновить
так тогда вторая строка от первой отличается и коллапса не будет, условиями просто определить что менять,
если у одного пользователя два или больше слотов с одинаковым кол-вом предметов, а изменить надо только одну строку, тогда и будет
update ... что_на_что_где_поменять ... limit 1
но я и сам бы не сторонник такого был, про инкремент надуманная проблема, что он быстро закончится, хватит его на очень долго
Разработка и продвижение сайтов. Дизайн
|
|
|
| |
| Quieteroks | Дата: Вторник, 30 Апреля 2013, 18:51 | Сообщение # 10 |
|
частый гость
Сейчас нет на сайте
| lvovand, Хорошо, если надуманная, подскажите, как эту надуманную проблему решить в момент, когда она возникнет?
Я сейчас о том, как можно сбросить поле автоинкимента? Грубо говоря у меня израсходовано половина индексов, из них в базе осталось около миллиона реально существующих записей, причем номера в этом случае будут как расческа, как ее почистить и обновить?
Если вам все равно где вы находитесь, значит вы еще не заблудились.
|
|
|
| |
| Tiendil | Дата: Вторник, 30 Апреля 2013, 18:56 | Сообщение # 11 |
|
участник
Сейчас нет на сайте
| Цитата (Quieteroks) Поскольку нет такого типа данных, как bigint в PHP.
Что, серьёзно нет? Уже ж 2013 год, 64-битной архитектуре уже незнамо сколько лет, как же они живут? Я думал даже самые слоупоки сделали.
В любом случае, про php в исходном посте ни слова нет, может и не на нём пишут.
Участвовал в разработке Order of War (C++ UI & логика) и WoT (Python портал worldoftanks.ru почти всё :-) )
Текущий проект: the-tale.org - indie mmozpg
|
|
|
| |
| lvovand | Дата: Вторник, 30 Апреля 2013, 19:18 | Сообщение # 12 |
|
старожил
Сейчас нет на сайте
| так посчитай сколько чего нужно чтобы проблема возникла, это нужны десятки-сотни тысяч игроков, тысячи онлайна, чтобы постоянно что-то добавлялось. При тех количествах много других еще проблем может открыться.
Для чистки остановить игру, используемые записи перенести во временную таблицу, текущую таблицу переименовать/заархивировать/удалить/очистить, создать новую таблицу и внести в нее данные из временной, не копируя сами индексы, а оставив их тому же автоинкременту. Скриптом все это сделается довольно быстро и номера пойдут по порядку
Разработка и продвижение сайтов. Дизайн
Сообщение отредактировал lvovand - Вторник, 30 Апреля 2013, 19:19 |
|
|
| |
| Quieteroks | Дата: Вторник, 30 Апреля 2013, 19:32 | Сообщение # 13 |
|
частый гость
Сейчас нет на сайте
| Tiendil,
Цитата (Tiendil) Что, серьёзно нет? Уже ж 2013 год, 64-битной архитектуре уже незнамо сколько лет, как же они живут? Я думал даже самые слоупоки сделали.
В любом случае, про php в исходном посте ни слова нет, может и не на нём пишут.
Я же говорю, потери имеются. Если где либо привести тип данных в инт, как правило это будет далеко не то же число, что и в базе.
И не дай бог какую либо математическую операцию с ними произвести...
Вопрос про базу, с уточнением, что хочется ответ без бигинта. А какой язык, это в данном случае не так важно.
Почему все сходятся к бигинту или переходят на оскорбления?
Что, неужели никто не знает варианта реализации именно той, что я спросил.
Может я вот какой нить шизофреник и у меня панический страх перед бигинтом и вообще к автоинкименту у меня глубокая неприязнь.
Не с просто же я именно это спрашиваю. Вот есть пример реализации без автоинкимента: http://wiki.ytdb.ru/index.php/Character_inventory
Но нет никаких подсказок как они так это реализуют и индексов не видно...Добавлено (30.04.2013, 19:32)
---------------------------------------------
lvovand,
Цитата (lvovand) так посчитай сколько чего нужно чтобы проблема возникла, это нужны десятки-сотни тысяч игроков, тысячи онлайна, чтобы постоянно что-то добавлялось. При тех количествах много других еще проблем может открыться.
Да какая разница. Сейчас у меня навящевая идея что именно это поле и именно тут может закончится.
Когда те проблемы вылезут, будет понятно, что решат нужно их и искать решение их, а если к ним еще и эта проблема добавится, то так вообще кранты будут.
Если вам все равно где вы находитесь, значит вы еще не заблудились.
|
|
|
| |
| lvovand | Дата: Вторник, 30 Апреля 2013, 19:33 | Сообщение # 14 |
|
старожил
Сейчас нет на сайте
| индекс кстати виден
item - первичный ключ
от себя, я бы и персонажа сделал индексным полем
избавляйся от страхов надуманных, реально ни к чему
так а если без ключевого поля, то что не понятно? просто при обновлении данных придеся в условии писать не первичный ключ а сравнивать по многим или всем столбцам, чтобы обновлялась только одна запись в таблице, если есть одинаковые записи, то при запросе UPDATE ставить LIMIT 1, хочешь чтобы пользователь делал свою сортировку, ну значит еще поле сортировки добавить
Разработка и продвижение сайтов. Дизайн
|
|
|
| |
| Quieteroks | Дата: Вторник, 30 Апреля 2013, 19:48 | Сообщение # 15 |
|
частый гость
Сейчас нет на сайте
| Цитата (lvovand) индекс кстати виден
item - первичный ключ
Вот тут я вообще не понял смысла в этом индексе. Не думаю, что достаточно его для запросов.
Сервер то у них С++ и постоянно поддерживает соединение с клиентом.
lvovand,
Вот же меня муза посетила...
Цитата (Quieteroks) Я думал что guid (userid) и bagslot могут как то это гарантировать для сумки, а у экипировки этот показатель слота нужно будет отслеживать и удалять ячейку с слотом.
А для экипировки возможно будут гарантировать guid (userid) и slot, и контролировать, что бы не было одинаковых слотов в экипировке.
Вот только я не знаю, составные индексы делать или обычные и вообще, как составные индексы себя поведут в ситуации использования одинакового первичного поля.
Если вам все равно где вы находитесь, значит вы еще не заблудились.
|
|
|
| |
| lvovand | Дата: Вторник, 30 Апреля 2013, 19:56 | Сообщение # 16 |
|
старожил
Сейчас нет на сайте
| мне про тот индекс тоже непонятно, и зачем он PRIMARY
сделай таблицу, сделай достаточное количество тестовых записей, и сделай тесты с разными индексами. Сделай EXPLAIN запросов, посмотри за какое время будут запросы выполняться, картина и прояснится
Разработка и продвижение сайтов. Дизайн
|
|
|
| |
| Quieteroks | Дата: Вторник, 30 Апреля 2013, 20:04 | Сообщение # 17 |
|
частый гость
Сейчас нет на сайте
| lvovand, в общем мало кто по тематике знает...
Буду пробовать тогда тесты проводить. Про explain спасибо, еще про него ничего не читал и не пользовался.
Блин, столько людей игры делают, а ничего невозможно подходящего найти в сети по сложным вопросам.
Если вам все равно где вы находитесь, значит вы еще не заблудились.
|
|
|
| |
|
