Дизайн базы данных инвентаризации

Я новичок в использовании MySQL, и я пытаюсь понять, каков наиболее эффективный способ хранения предметов инвентаря игрока в моей базе данных.

Итак, вот установка:

Существует таблица под названием 'player', и каждому игроку назначается уникальный 'playerid', который устанавливается в качестве основного индекса таблицы.

У каждого игрока может быть до 24 предметов в инвентаре, и информация об этих предметах хранится в таблице под названием 'player_inventory'. Эта таблица имеет следующие поля:

playerid, slotid, uid, стек, использование, долговечность

'uid' – это идентификатор предмета, а также 'stack', 'uses' и 'durability'. являются просто значениями, которые нужны каждому предмету (например, тот же тип предмета в другом слоте может иметь более низкую "долговечность").

Проблема в том, что я не могу установить индекс для 'playerid' в таблице инвентаря, потому что для каждого игрока существует до 24 записей слотов, и ни одно из других полей не может быть уникальным.

Поэтому я беспокоюсь, когда в этой таблице есть инвентарь 10 000 игроков, потенциально может быть 240 000 записей в этой таблице без индекса, когда я иду к ней, чтобы запросить ее - что-то подсказывает мне, что это может быть очень медленно?

У меня довольно ограниченные знания о том, как оптимизировать мою базу данных, любые советы очень приветствуются.


person Matthew    schedule 12.09.2011    source источник


Ответы (3)


Индексы, в том числе уникальный индекс для первичного ключа, могут быть определены для нескольких столбцов.

ALTER TABLE player_inventory ADD PRIMARY KEY (playerid, slotid);

Это означает, что комбинация значений в этих двух столбцах должна быть уникальной. Но данный playerid может встречаться в нескольких строках, а данный slotid может встречаться в нескольких строках.

person Bill Karwin    schedule 12.09.2011
comment
А, похоже, это может быть полезно. Я проверю это. - person Matthew; 12.09.2011

Лучше иметь 3 стола.

  1. tblPlayer (idPlayer INT PK NOT NULL AUTO_INCREMENT, имя пользователя, пароль и т. д.)
  2. tblItemInventory(idItemInventory INT PK NOT NULL AUTO_INCREMENT, idPlayer FK, idItem FK, ..)
  3. tblItem (idItem INT PK NOT NULL AUTO_INCREMENT, долговечность, использование, )

tblItem имеет до 24 (idItem=24)

person ronron    schedule 05.07.2012

Есть две мысли об установке индекса для таблицы, такой как ваш инвентарь. Один включает в себя создание суррогатного ключа, в основном автоинкрементного индекса для таблицы, который не имеет отношения к данным вашего приложения. Это только там, чтобы служить индексом.

Другой способ применить индекс — использовать комбинацию playerid и uid. Хотя, если у игрока может быть более одного стека одного и того же предмета (как в Diabo или MMO), вы, вероятно, можете использовать комбинацию playerid и slotid в качестве индекса. Вы можете иметь составной ключ, состоящий из более чем одного ключа в MySQL.

person Extrakun    schedule 12.09.2011
comment
У игрока могут быть предметы с одним и тем же «uid» в нескольких слотах, поэтому последний не будет работать. Если бы я использовал индекс с автоинкрементом, пришлось бы мне использовать это поле в своих запросах, чтобы получить пользу от индекса, или оно помогает просто быть там? - person Matthew; 12.09.2011
comment
Если они могут иметь одинаковый uid в одном и том же инвентаре, будет ли работать составной ключ playerid и slotid? Если вы используете поле с автоинкрементом в качестве своего ПК, это ускорит запросы, если вы его используете. Это также может помочь с базовой организацией данных, но я не уверен. - person Extrakun; 12.09.2011
comment
Является ли составной ключ чем-то вроде предложенного Биллом Карвином выше? Если это так, то это звучит как направление к голове. - person Matthew; 12.09.2011
comment
да. Это ключ, состоящий более чем из двух полей. - person Extrakun; 12.09.2011