Как хранить объекты в MySQL?

Я работаю над своей первой игрой, содержащей элементы (построил небольшой вариант раньше, тип стратегии, но не очень сложный). Я думал о чем-то подобном для дизайна db, так как это будет почти то же самое в каждом магазине. Я думаю о подключении магазина к пользовательским элементам (не уверен, понимаете ли вы, о чем я думаю):

shopname
  shopNameId, shopName
shopCategory
 shopCategoryId, shopNameId shopCategoryName,
shopItems
 shopItemId, armourId, oneHandedWeaponId, twohandedWeapoinId,

это будет для магазина. Теперь

oneHandedWeapons
 oneHandedWeaponId, weaponName, weaponMinAtk, weaponMaxAtk, ...

otherAttributes,

oneHandedExtendedAttributes
 oneHandedExtendId, oneHandedWeaponId, ... otherAttritubes,

и снова для других типов элементов. Это npc будет единственным местом, где они могут покупать предметы.

Теперь, когда пользователь купил новый предмет из одного из магазинов, я должен вставить идентификатор этого элемента в таблицу инвентаря no? Я думал о структуре, подобной этой, для тайника, основанного на 10 слотах.

userStash
userStashId, userId, slot1, slot2, slot3, slot4, slot6, slot7, slot8, slot9, slot10

теперь на каждом слоте я могу вставить идентификатор этого элемента.

Теперь мои вопросы:

  1. Это нормально, как я это сделал?
  2. Вы видите какие-либо проблемы?
  3. Есть ли у вас какие-либо советы?
  4. Можете ли вы дать мне другой идеал /другой пример, как мне сделать эту часть?
5 голосов | спросил Bogdan 3 +04002011-10-03T19:39:08+04:00312011bEurope/MoscowMon, 03 Oct 2011 19:39:08 +0400 2011, 19:39:08

2 ответа


12

Хотя эта предлагаемая реализация работоспособна, она не очень масштабируема - и масштабируемость должна быть одной из причин, по которой вы считаете, что используете что-то MySQL. Вам не нужна «база данных» для хранения предметов и данных магазина /поставщика для игры, особенно не простая однопользовательская игра. Простое хранение данных в плоских файлах (текст, XML или какой-либо двоичный формат, который вы изобретаете) будет работать так же хорошо и, вероятно, будет намного проще реализовать и поддерживать. Вы не должны использовать базу данных, такую ​​как MySQL, если вам не нужна то, что предлагает база данных, что никакое другое решение не делает. Я не верю, что вы это делаете.

Тем не менее, некоторые конкретные критические замечания:

  • shopCategory разработан таким образом, чтобы каждая категория была уникальной для магазина. «Мечи» в магазине А - это не та же категория, что и «мечи» в магазине Б. Это, вероятно, нежелательно, так как это, скорее всего, приведет к сложности, которая не нужна; он также создает раздувание данных. Категории, вероятно, не обязательно должны быть привязаны к магазину.
  • shopItems подразумевает, что в магазине есть один набор предметов (хотя между магазинами и набором предметов отсутствует связь), и что набор предметов содержит ровно один из каждого фиксированного класса оружия. В магазине невозможно увидеть два разных вида оружия с двумя руками.
  • Что вызывает вопрос, если класс оружия, если он исправлен в дизайне таблицы, почему существует таблица категории?
  • Таблица «stash» пользователя подразумевает фиксированный верхний предел для хранения файлов, что в будущем будет очень сложно изменить. Это плохая идея.

Это звучит как ваш первый набег на обе игры с системами элементов и дизайном базы данных, что является еще одной причиной, по которой я бы рекомендовал вам полностью исключить базу данных. Система, которую вы хотите моделировать, имеет несколько многих-ко-многим отношения, которые не сразу очевидны, как захватить неофит БД.

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

Shop
------------------
shopID   | integer
shopName | text

и один, определяющий каждый элемент в игре:

Item
------------------
itemID   | integer
itemName | text
itemType | integer
...

У вас может быть третья таблица, определяющая отношения (многие ко многим) между магазинами и предметами, которые они переносят; каждая запись в этой таблице представляет конкретный экземпляр определенного типа элемента (из таблицы элементов) для конкретного магазина (из таблицы магазинов).

ShopInventory
-------------
shopId | integer (the shop ID that owns this item)
itemId | integer (the ID of the item)

Итак, если Магазин Боба - магазин ID 23, и он имеет 4 копии Awesome Longsword (пункт 2) и две копии Potion of Hangover Resistance (позиция 73), таблица ShopInventory может выглядеть так:

shopId | itemId
---------------
23     | 2
23     | 2
23     | 2
23     | 2
23     | 73
23     | 73
... etc ...

Это действительно очень реалистичный обзор отношений «многие-ко-многим» и способы их реализации. Они действительно нужны, чтобы сделать модель, о которой вы говорите, и я настоятельно рекомендую вам исследовательский дизайн БД намного больше, если вы действительно хотите использовать БД для своих товаров. Но я бы посоветовал вам more просто не докучать с базой данных вообще. Храните ваши данные в текстовых файлах или XML-файлах, пока вы выясняете, как наилучшим образом разработать системы товаров /инвентаря /магазина.

Позднее будьте обеспокоены базами данных.

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

ответил Josh 3 +04002011-10-03T20:13:21+04:00312011bEurope/MoscowMon, 03 Oct 2011 20:13:21 +0400 2011, 20:13:21
3

1 Нет ... По крайней мере, не так, как я бы это сделал. Это может быть именно то, что вам нужно, но я действительно не вижу логики.

2 Да, несколько. Например:

  • Ваш тайник пользователя нарушает принципы 1NF: не нужно иметь несколько столбцов для хранения одного и того же домена данных (но это не самое главное).
  • Ваш магазин не эффективен, если каждый предмет не составлен точно из брони, оружия с одной рукой и двуручного оружия. Это не тот случай, когда предполагается, что оружие с оружием не всегда сдано, а наоборот.

3 Возможно, вы должны изменить свою структуру данных или использовать более динамичную систему хранения (XML, JSON ...), где вы могли бы сделать несколько вещей, которые не являются практическими с SQL.

<shop id="45u2y">
  <items>
    <item id="broad2">
    ...
  </item>
</shop>

<items>
  <item id="broad2">
    <name lang="en">Broad Sword</name>
    <transform id="twoHanded"><dmg type="cut">3d6+2</dmg><slot id="hand"/><slot id="hand"/></transform>
    <transform id="oneHanded"><dmg type="cut">2d6</dmg><slot id="hand"/></transform>
  </item>
</item>

4 Если бы мне пришлось использовать SQL, я бы, вероятно, сделал бы что-то вроде этого:

shopItems
 shopItemId, shopItemStatus

items
 itemId, itemName, itemCathegory

itemsTransformators
 itemId, transformatorId, transformatorType, transformatorCondition

Etc ... В этом случае я действительно считаю, что SQL не лучший выбор. Я бы определенно использовал пользовательскую систему хранения, XML или действительно нужен другой тип БД. ex: eXistDB http://exist.sourceforge.net/

ответил Coyote 3 +04002011-10-03T20:25:38+04:00312011bEurope/MoscowMon, 03 Oct 2011 20:25:38 +0400 2011, 20:25:38

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132