Items sql table

I am building a textbased game, and I have problem of how to build/structur my SQL table for items.

Item can be anything from weapon, a fruit, armor, etc. But I'm not sure how to properly design this.

For example

Iron Sword Str +4 Health +3

(Or something like that)

But if its a fruit item

Fruit of Health (lol)

+5 health when eated

---

Any tips or ideas? The questi开发者_如何学Con is How do I structure this SQL table?

---

Store different types of object in different tables.
Give each table the proper columns for the respective kind of object it stores.

CREATE TABLE Weapons (WeaponId INT PRIMARY KEY, Name VARCHAR(20), Strength INT);
CREATE TABLE Foods (FoodId INT PRIMARY KEY, Name VARCHAR(20), HealthBonus INT);

If you want all types of objects to have some common attributes, like weight or purchase price, then you could create a general Items table that has those common attributes.

CREATE TABLE Items (ItemId INT AUTO_INCREMENT PRIMARY KEY, 
  Weight NUMERIC(9,2), Cost NUMERIC(9,2));

You'd make the WeaponId and FoodId primary keys from the other tables would each match one of the ItemId values in Items. When you want to create a new weapon, you'd first add a row to Items which would generate a new ItemId value, then use that value explicitly as you insert into Weapons.

See the Class Table Inheritance pattern.

---

Re your question below.

If you are querying for a specific weapon, you can join:

SELECT * FROM Items i JOIN Weapons w ON w.WeaponId = i.ItemId
WHERE w.Name = 'Iron Sword';

If you are query for all items in the character's backpack, you'd have to do multiple joins:

SELECT i.*, COALESCE(w.Name, f.Name, t.Name) AS Name,
  CONCAT_WS('/',
    IF (w.WeaponId, 'Weapon', NULL),
    IF(f.FoodId, 'Food', NULL),
    IF(t.TreasureId, 'Treasure', NULL)
  ) AS ItemType
FROM Items i 
LEFT OUTER JOIN Weapons w ON w.WeaponId = i.ItemId
LEFT OUTER JOIN Foods f ON f.FoodId = i.ItemId
LEFT OUTER JOIN Treasure t ON t.TreasureId = i.ItemId
etc.;

If a given Item matches a Weapon but not a Food, then the columns in f.* will be null. Hopefully a given ItemId matches an Id used in only one of the specific subtype tables. On the other hand, it allows a given item to be both a weapon and a food (for instance, vegan cupcakes, which can be effective projectiles ;-).

---

Sounds like you need a table of attributes (strength, health, etc.). Then a table of the items (name, description, etc) and an association linking the two together (obviously linking by related id's rather than text for normalization, but this is just to demonstrate).

Item        Attr  Value
Iron Sword  Str   +4
Iron Sword  Hlth  +3
Fruit       Hlth  +5

---

Right answears given above.. They are different approaches... The second one requires good knwledge of OOP.

I want to mention an other thing, I suggest you read some tutorial on Entity Relational diagram-design. I gues for a game you will probably need to study a few basic things only so it will take you only some hours I guess.

There are many things to consier while designing... for example:

1. Entity = A thing that can logically stand on its own with its own attributes: Customer, Supplier, Student, Departement are some strong entities etc. Works for, belongs to etc are not entities but relations that associatin entities together.

2. An entity becomes a table. Strong entities (that have no dependencies) become tables with a simple primary key and usually without accepting any foreign keys. Phone number is not a strong-indepndent entity every time a customer is deleted the phone has no menaing, every time a phone is deleted hte customer has still meaning. Phone is an attribute but because of multiple values it becomes finally a table.

All these are not to tutor er design just to mention that db design in not something to take lightly, it can save you or give you big pain... depends on you.