"По сути строки. Причем в этом случае будет не просто обновление нахождения предмета в инвентаре, а уже два отдельных запроса (добавление/обновление и удаление в сумке).".
Что за глупость? У тебя есть предмет как объект, у него есть свойства, вот одним из таких и будет его позиция в инвенторе. Никаких добавить и удалить, только изменить положение:
UPDATE `item` SET `x` = 5, `y` = 10 WHERE `id` = 100000
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Полная Версия: MySQL без идентификатора строки
| Цитата |
| А автоинкремент можно и свой пилить используя MAX число и делать +1 |
inpost
1. Если я организую лут, то накопится много строк. Собрал, продал... А вот про не удаление строк, я даже не думал и это мне кажется весьма сомнительным делом, накапливать строки, которые не будут возможно никогда использоваться.
2. А суть десятка таблиц? Каждая отвечает за свой тип предметов? А потом собирать по нескольким таблицам все предметы?
3. Да, у одного игрока не более 100 строк получится. Но один предмет может лежать в разных строках. И тогда же этого индекса может быть недостаточно?
Или какой ID ты имеешь в виду, если не ID предмета?
Valick
Я правильно понял, что ты предлагаешь сделать таблицу фиксированной ширины?
Т.е. не одно поле с предметом в строке, а сотня полей с id предмета и столько же с количеством предметов в слоте? А кто про нормализацию таблиц говорил?
Вариант с bigint мне больше нравится, тем более если не трогать идентификатор строки, то PDO справляется вполне добросовестно, со своими подготовленными выражениями.
Вот что еще надумал, возможно запрос будет иметь только два условия, которых должно быть достаточно. bagslot имеется только у предмета в сумке. Соответственно нужен только guid и bagslot? В случае экипировки guid и slot (при условии один слот, один предмет экипировки).
Почему никто не предлагает вариантов в плане отказа от номера строки в часто обновляемых таблицах? Ведь это интересно же. Возможно при отказе от номера строки, ее размер займет индекс, но при этом будет меньше проблем с возможным ограничением по количеству ключей через год/два/три...
Как лучше сделать индексы? Составные или обычные?
Вот более интересный вопрос. Почему на него никто не отвечает?
1. Если я организую лут, то накопится много строк. Собрал, продал... А вот про не удаление строк, я даже не думал и это мне кажется весьма сомнительным делом, накапливать строки, которые не будут возможно никогда использоваться.
2. А суть десятка таблиц? Каждая отвечает за свой тип предметов? А потом собирать по нескольким таблицам все предметы?
3. Да, у одного игрока не более 100 строк получится. Но один предмет может лежать в разных строках. И тогда же этого индекса может быть недостаточно?
Или какой ID ты имеешь в виду, если не ID предмета?
Valick
Я правильно понял, что ты предлагаешь сделать таблицу фиксированной ширины?
Т.е. не одно поле с предметом в строке, а сотня полей с id предмета и столько же с количеством предметов в слоте? А кто про нормализацию таблиц говорил?
Вариант с bigint мне больше нравится, тем более если не трогать идентификатор строки, то PDO справляется вполне добросовестно, со своими подготовленными выражениями.
Вот что еще надумал, возможно запрос будет иметь только два условия, которых должно быть достаточно. bagslot имеется только у предмета в сумке. Соответственно нужен только guid и bagslot? В случае экипировки guid и slot (при условии один слот, один предмет экипировки).
Почему никто не предлагает вариантов в плане отказа от номера строки в часто обновляемых таблицах? Ведь это интересно же. Возможно при отказе от номера строки, ее размер займет индекс, но при этом будет меньше проблем с возможным ограничением по количеству ключей через год/два/три...
Как лучше сделать индексы? Составные или обычные?
Вот более интересный вопрос. Почему на него никто не отвечает?
inpost
| Цитата |
| "По сути строки. Причем в этом случае будет не просто обновление нахождения предмета в инвентаре, а уже два отдельных запроса (добавление/обновление и удаление в сумке).". Что за глупость? У тебя есть предмет как объект, у него есть свойства, вот одним из таких и будет его позиция в инвенторе. Никаких добавить и удалить, только изменить положение: UPDATE `item` SET `x` = 5, `y` = 10 WHERE `id` = 100000 |
Так если же ДВЕ таблицы, то не изменение расположения в инвентаре, а перемещение из таблицы в таблицу.
А зачем вторая? Не понимаю в её необходимости.
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
| Цитата |
| А зачем вторая? |
| Цитата |
| Я правильно понял, что ты предлагаешь сделать таблицу фиксированной ширины? |
нет, предлогать такое было бы несколько глупо с моей стороны
_____________
Стимулятор ~yoomoney - 41001303250491
inpost
Вот и я не понимаю зачем вторая.
Valick
Это одна сущность, сущность предмета у персонажа в инвентаре. А инвентарь - это не только сумка, но и вся экипировка и прочее.
Вот и я не понимаю зачем вторая.
Valick
Это одна сущность, сущность предмета у персонажа в инвентаре. А инвентарь - это не только сумка, но и вся экипировка и прочее.
| Цитата |
| нет, предлогать такое было бы несколько глупо с моей стороны |
А по запросу было понятно именно что Вы 22 слот (как ячейка в таблице) приписывается в другую таблицу в качестве значения для другой таблице (такой же фиксированной ширины с ограниченным набором элементов).
| Цитата |
| А по запросу было понятно |
да небыло конкретно никакого запроса, это всего лишь теория, просто пример
| Цитата |
| А инвентарь - это не только сумка, но и вся экипировка |
ну дык я свой велосипед, тоже могу обзывать батискаффом, но нырять с ним от этого легче не станет.
_____________
Стимулятор ~yoomoney - 41001303250491
Valick
| Цитата |
| да небыло конкретно никакого запроса, это всего лишь теория, просто пример |
Ну так пример бы тогда более реальный...
А так, от запроса, который Вы привели мало толку и не поможет переместить предмет из сумки в экипировку. В любом случае нужно два запроса. Один, даже если такой изощренный, но на добавление строки, обновление возможно только если подменять предметы. Второй, для удаления строки...
| Цитата |
| ну дык я свой велосипед, тоже могу обзывать батискаффом, но нырять с ним от этого легче не станет. |
Это тоже верно, но я сколько не смотрел и где бы не читал, инвентарь = таблице со всеми предметами пользователя.
Вы же не будете писать в разные таблицы счет на пополнение баланса и счет на вывод средств. Сущности разные или одинаковые? Они и разные и одинаковые, но Вы же их не будете разделять. Но у них будут разные "флаги/статусы" в одной таблице. Нормализация разная бывает, излишней она так же не должна быть.
| Цитата |
| Второй, для удаления строки... |
Да чтож вы так к удалению привязались... удаление строк должно быть только если вы выбросили сумку, и то удалить можно только идентификатор владельца этой сумки, а саму сумку вместе с содержимым можно оставить "валяться на дороге" если это позволяет логика игры.
| Цитата |
| пополнение баланса и счет на вывод средств. Сущности разные или одинаковые? |
Сущность одна - "баланс", а точнее расчетный счет.
_____________
Стимулятор ~yoomoney - 41001303250491
Valick
| Цитата |
| Да чтож вы так к удалению привязались... |
А смысл копить неопознанные строки? Чтобы база пошире была и запросы подольше выполнялись? Или Вы предлагаете перед добавлением нового предмета в инвентарь, дополнительно проверять наличие свободного предмета в базе как неопознанного? Т.е. по мимо трех запросов (примерно) на генерацию страницы, запроса на получение информации о добавляемых предметах, и запроса на добавление, еще искать лежащий мертвым грузом предмет в базе? Мне кажется это не разумно, я и так уже подумывал часть информации положить в файлы, чтобы базу не трогать постоянно по мелочам. Даже подумывал сумку в файл посадить, для каждого игрока, но совсем не уверен в этом.
| Цитата |
| можно оставить "валяться на дороге" если это позволяет логика игры. |
Нет, пока что игра не позволяет валяться предметы на дороге, в силу отсутствия самой дороги.
| Цитата |
| Сущность одна - "баланс", а точнее расчетный счет. |
Так же и с инвентарем, сущность у него одна. И экипировка не является частью чего то другого. Оно все принадлежит игроку и является предметом. Как различные счета на расчетном счете реального человека.
Блин, какой прям флейм тут устраиваем...
Так что Вы можете посоветовать в сторону ключей?
Или все же все уверены, что 4млр записей должно хватить всем? А если не хватит, то можно взять bigint и обойти на долгое время это ограничение...
| Цитата |
| А смысл копить неопознанные строки? |
А чего там копить? сумка например 20 слот (как правило забита под завязку, свободных один два слота) Вы каждый раз будете добавлять/удалять эти два слота? Вы больше потеряете на переиндексации полей таблицы.
Купил себе сумку, зарезервировал в таблице 20 строк и успокоился, дальше только UPDATE этих строк.
Купил сумку 28 слот, просто заменил id сумки и добавил 8 строк, все вещи как лежали, так и лежат.
___
Представляете купила ваша жена сумочку от louis vuitton, а она зашита сверху. Сходила в магазин купила помаду, салфетки, лак и тд. Пришла в ателье просит распороть сумку, чтобы все туда положить, распороли, положила. Потом закончились салфетки, и она бегом в ателье с просьбой ушейте мне сумку на объем занимаемый салфетками...
___
| Цитата |
| Или все же все уверены, что 4млр записей должно хватить всем? |
разделите 4млр на 20 (или какие там у вас сумки), получите максимальное количество игроков, потянет сервачёк-то?
_____________
Стимулятор ~yoomoney - 41001303250491
| Цитата |
| Так же и с инвентарем, сущность у него одна. И экипировка не является частью чего то другого |
блин, ну не мешайте "мух с котлетами"
экипировка: ид персонажа, ид голова, ид шея, ид грудь, ид перчатки, ид кольца, ид штаны, ид ботинки, ид сумка и даже ид маунт - все это одна строка таблицы и все это только идентификаторы предметов - это таблица связи. все что лежит в сумке вас мягко говоря не колышет.
таблица bags
идентификатор строки, идентификатор сумки, номер слота, идентификатор предмета, количество
если есть предметы занимающие несколько слот в сумке (как например в DS или NWN) то чуть сложнее обновление, но количество строк не меняется ни разу.
___
по поводу переполнения таблиц и все такое, как думаете зачем в той же WoW профилактика каждую среду на несколько часов?
_____________
Стимулятор ~yoomoney - 41001303250491
Valick
| Цитата |
| Вы каждый раз будете добавлять/удалять эти два слота? |
Нет, если предметы уже в сумке, то им просто меняется их расположение (bagslot).
| Цитата |
| Купил себе сумку, зарезервировал в таблице 20 строк и успокоился, дальше только UPDATE этих строк. |
Вот это уже более понятно. Но:
| Цитата |
| разделите 4млр на 20 (или какие там у вас сумки), получите максимальное количество игроков, потянет сервачёк-то? |
Одновременно играющих нет и не нужно, столько играть не будет. И вот то самое но, что Выше. Не каждый останется в игре более чем на сутки. Кто то просто так зарегистрируется, узнать что это такое, а 20 строк таблице им отдай. Они ими не воспользуются никогда, но таблица будет расти с каждым новым игроком. И зачем такие затраты, если на миллион регистраций, играть будут 5-7 тысяч.
| Цитата |
| блин, ну не мешайте "мух с котлетами" экипировка: ид персонажа, ид голова, ид шея, ид грудь, ид перчатки, ид кольца, ид штаны, ид ботинки, ид сумка и даже ид маунт - все это одна строка таблицы |
Я их и не мешаю. А одна строка на экипировку, я от этой идеи отказался еще год назад, когда начинал изучать MySQL и PHP. Может я плохо что то еще понимаю, но это самый неудобный момент в таблице, когда ID лежат в одной строке.
С сумкой конечно интересный момент, но Вы сами мешаете мух и котлеты. В данном случае ближе вариант с банком, а не с сумочкой и ее ушиванием. Банк не будет хранить пустую полочку для Вас, если Вы ее не занимаете (депозит не рассматриваем, мне за строчку в базе никто не платит). Банк ломится от желающих поместить денежку в сейф, все забито, кроме Вашей полочки, куда можно положить денежки еще десятка людей. Вы ей сейчас не пользуетесь, Вам не показывают Вашу полочку, но Вы знаете, что у Вас есть возможность положить свои сбережения туда, но Вам же не важно где эта полочка.
Здесь расположена полная версия этой страницы.