Need a tip on simple MySQL db design

Question

I am trying to make a simple item database using MySQL for a game. Here is what my 3 tables would look like

     items
     itemId | itemName 
    --------------         


        

Answer 1

Why do you have an attribute table ?

Attributes are columns, not tables.

The website link tells us nothing.

The whole idea of a database is that you join the many small tables, as required, for each query, so you need to get used to that. Sure, it gives you a grid, but a short and sweet one, without Nulls. What you are trying to do is avoid tables; go with just one massive grid, which is full of Nulls.

(snip)

Do not prefix your attribute names (column names) with the table name, that is redundant. This will become clear to you when you start writing SQL which uses more than one table: then you can use the table name or an alias to prefix any column names that are ambiguous.

The exception is the PK, which is rendered fully, and used in that form wherever it is an FK.

Browse the site, and read some SQL questions.

After doing that, later on, you can think about if you wantstrength and defense to be attributes (columns) of type; or not. Et cetera.

Responses to Comments 30 Nov 10

.
Excellent, you understand your data. Right. Now I understand why you had an Attribute table.

1. Please make sure those 10 examples are representative, I am looking at them closely.

   • Type:Gem Name:Emberspark Pendant ... Or, is NeckMiscellaneous a type ?
   • Is Unique a true ItemType ? I think Not
   • Action.Display "Please return to a Season Organizer"
   • Where are the Attrinutes for AttackPower and HitRating ?
     .

2. How many different types of items (of 35,000) are there, ala my Product Cluster example. Another way of stating that question is, how many variations are there. I mean, meaningfully, not 3500 Items ÷ 8 Attributes ?

3. Will the item_attributes change without a release of s/w (eg. a new Inner Strength attribute) ?

4. Per Item, what Attributes are repeating (more than one); so far I see only Action ?

5. It is a game, so you need a db that is tight and very fast, maybe fully memory resident, right. No Nulls. No VAR Anything. Shortest Datatypes. Never Duplicate Anything (Don't Repeat Yourself). Are you happy with bits (booleans) and vectors ?

6. Do you need to easily translate those regexes into SQL, or are you happy with a serious slog for each (ie. once you get them working in SQL they are pretty stable and then you don't mess with it, unless you find a bug) (no sarcasm, serious question) ?

   6.1 Or maybe it is the other way round: the db is disk-resident; you load it into memory once; you run the regexes on that during gameplay; occasionally writing to disk. Therefore there is no need to translate the regexes to SQL ?

Here's a Data Model of where I am heading, this not at all certain; it will be modulated by your answers. To be clear:

• Sixth Normal Form is The Row consists of the Primary Key and, at most, one Attribute.

• I have drawn (6.1) not (6), because your data reinforces my belief that you need a pure 6NF Relational database

• My Product Cluster Data Model, the better-than-EAV example, is 6NF, then Normalised again (Not in the Normal Form sense) by DataType, to reduce no of tables, which you have already seen. (EAV people usually go for one or a few gigantic tables.)

• This is straight 5NF, with only the 2 tables on the right in 6NF.

Link to Game Data Model

Link to IDEF1X Notation for those who are unfamiliar with the Relational Modelling Standard.

Response to Edit #2 05 Dec 10

1.1. Ok, corrected.

1.2. Then IsUnique is an Indicator (boolean) for Item.

1.3. Action. I understand. So Where are you going to store it ?

1.4. NeckMiscellaneous means that item is in both categories of Neck and Misc. That means two separate Item.Name=Emberspark Pendant, each with a different Category.

.
2. and 5. So you do need fast fast memory-resident db. That's why I am trying to get you across the line, away from GridLand, into RelationalLand.
.
3. Ok, we stay with Fifth Normal Form, no need for 6NF or the Product Cluster (tables per Datatype). Sofar the Values are all Integers.
.
4. I can see additionally: Level, RequiredLevel, IsUnique, BindsPickedUp, BindsEquipped.
.
5. Bits are booleans { 0 | 1 }. Vectors are required for (Relational) projections. We will get to them later.
.
6. Ok, you've explained, You are not translating regular expressions to SQL. (Slog means hard labour). .
7. What is Category.ParentId ? Parent Category ? That has not come up before.
.
8. Attribute.GeneratedId ?

Please evaluate the Data Model (Updated). I have a few more columns, in addition to what you have in yours. If there is anything you do not understand in the Data Model, ask a specific question. You've read the Notation document, right ?

I have Action as a table, with ItemAction holding the Value:
Equip: increase attack power by 28 is Action.Name=Increase attack power by and ItemAction.Value=28.

Answer 2

You are dealing with a two common problems:

• Entities that are similar to each other but not identical (all items have a name and description, but not necessarily an intellect).
• A design in which you need to add attributes once the database is in production (you can pretty easily predict that at some point you'll need to add, for instance, a magic-resistance attribute to some items).

You've solved your problem by reinventing the EAV system in which you store both attribute names and values as data. And you've rediscovered some of the problems with this system (type checking, relational integrity).

In this case, I'd personally go with a solution midway between the relational one and the EAV one. I'd take the common columns and add them, as columns, to either the items table or, if items represents kinds of items, not individual ones, to the items_owners table. Those columns would include description and possibly type and in the example you gave, pretty much match up with the text columns. I'd then keep the existing layout for those attributes that are numerical ratings, making the value type int. That gives you type-checking and proper normalization across the integer attributes (you won't be storing lots of NULLs) at the expense of the occasional NULL type or description.

Answer 3

I think having the data_type column just further complicates the design. Why not simply have type and description be columns on the items table? It stands to reason that every item would have each of those values, and if it doesn't then a null would do just fine in a text column.

You can even further normalize the type by having an item_types table and the type column in items would be a numeric foreign key to that table. Might not be necessary, but might make it easier to key off of the type on the items table.

Edit: Thinking about this further, it seems like you may be trying to have your data tables match a domain model. Your items would have a series of attributes on them in the logic of the application. This is fine. Keep in mind that your application logic and your database persistence layout can be different. In fact, they should not rely on each other at all at a design level. In many small applications they will likely be the same. But there are exceptions. Code (presumably object-oriented, but not necessarily) and relational data have different designs and different limitations. De-coupling them from one another allows the developer to take advantage of their designs rather than be hindered by their limitations.