Как лучше организовать хранение игрового инвентаря в базе данных?

Question

[fortael]

Есть уже боевой проект, где есть таблица аккаунтов и там же прямо инвентарь, и прочие игровые показатели.
Выглядит это так: каждый существующий в игре предмет - это колонка с его кол-вом у игрока.

spoiler

Таких колонок 57 и с десяток других показателей. Само собой, масштабирования такая база не выдерживает. Аккаунты периодически вайпают, их в принципе не очень много. Индексы не особо помогают. Структура + обычный web хостинг:

spoiler

(на другом проекте, где колонок в 3 раза меньше, а записей больше подобный запрос занимает 0.0002)

Как существующую иерархию лучше всего расположить в базе? Есть идея сделать в отдельной таблице, где каждый предмет - это отдельная запись. По идеи запись нового должна быть дешевле, чем обновление одного и того же, но я не эксперт, чтобы утверждать. Вроде такого:
1 принадлежит Васе в кол-ве 3 шт
3 принадлежит Коле в кол-ве 1 шт
1 принадлежит Пете в кол-ве 4 шт
8 принадлежит Васе в кол-ве 1 шт

Но если, например, у человека будут все предметы - 200к аккаунтов * 57 предметов (это пока), даст ли это вообще какой-то прирост или только больше записей?

Comments

[Сергей Горностаев]

Отношение многие к многим для этого и придумали.

Answer 1

[Saboteur]

А почему масштабируемость не выдерживает?
В проектах типа Lineage2 (онлайн до 5000, зарегистрированных аккаунтов до 15000) - это не проблема.

КАЖДЫЙ предмет - это строка в таблице items, с указанием владельца.

Поля примерно такие:
item_id, owner_id, item_type, param1, param2, param3
item_id - уникальный номер предмета
owner_id - ID владельца, можно добавить поле для координат и времени хранения для тех предметов, которые лежат на земле. Периодически их можно удалять, а те, у которых время хранения 0 не удалять.
item_type - ID типа предмета, в отдельной таблице храните все предметы и их неизменяемые параметры (вес, материал, название, описание, ограничения по расам, по куда одевать, все такое)
param1...param10 - изменяемые параметры предмета (заточки, цвет, эффекты, состояние поломки)
Для предметов типа деньги, монеты, бутылки - можно сделать столбец с количеством, для остальных предметов это всегда 1.

Положение предмета (типа одет, или в рюкзаке), можно делать или в этой же таблице, или в таблице владельца.

Собственно не очень понятно, что вы имеете ввиду, когда считаете, что это не масштабируется.

Comments

[fortael]

Ну там, вроде, фактор возврата в игру больше. Хотя 200к тоже довольно мало аккаунтов, считаю. Под масштабированием я имею ввиду, конечно, сам рост данных. Чем их больше, тем база медленнее, это очень сильно заметно. Тоже сразу подумал посмотреть, как это сделано в mmo rpg. Лимит, само собой, есть - вот 57 колонок ну и игровой лимит. Спасибо за пример.

[Saboteur]

fortael: Тут другой момент, что у вас за проект. Поскольку если идет про веб-проект, где каждый http-запрос должен бегать в базу за предметами - это одно. В MMORPG база периодически обновляется, но не каждый клик, в основном все в памяти.
Например предметы, у которых нет овнера-игрока/кланового хранилища, в базу не сохраняются совсем - для них нет позиции, и при ребуте сервера пропадают.

В текстовом MUD, который я писал в 90-е, делалось проще - все хранится в памяти.
Раз в xx минут все данные игроков сохраняются в базу.
Чтобы данные были консистентными, и не было большой нагрузки - если игрок совершал любые действия, связанные с предметами, он "помечался", и при сохранении сохранялись данны всех помеченных игроков с их предметами, и метка снималась. Это позволяло сохранять не все, а только изменения.
Но вообще, смотрите не по количеству записей, а сделайте перфоманс тест.

Answer 2

[Wexter]

1 таблица - таблица пользователей с уникальным id
2 таблица - таблица всех возможных предметов с уникальным id, описанием и прочими нужными полями
3 таблица - хранит соответствие id пользователя из т1, id предмета из т2 и количество этого предмета у пользователя.
Выборку делать JOIN'ом