Har brug for et tip om simpelt MySQL db-design

Hvorfor har du en attribute tabel ?

Attributter er kolonner, ikke tabeller.

Hjemmesidelinket fortæller os intet.

Hele ideen med en database er, at du tilslutter de mange små tabeller, efter behov, for hver forespørgsel, så du skal vænne dig til det. Sikker på, det giver dig et gitter, men et kort og sødt, uden Nulls. Hvad du forsøger at gøre er at undgå tabeller; gå med kun et massivt gitter, som er fyldt med nuller.

(klip)

Undlad at præfikse dine attributnavne (kolonnenavne) med tabelnavnet, det er overflødigt. Dette vil blive klart for dig, når du begynder at skrive SQL, som bruger mere end én tabel:så kan du bruge tabelnavnet eller et alias til at præfikse alle kolonnenavne, der er tvetydige.

Undtagelsen er PK, som gengives fuldt ud og bruges i den form, uanset hvor det er en FK.

Gennemse webstedet, og læs nogle SQL-spørgsmål.

Efter at have gjort det, kan du senere tænke over, om du vil havestrength og defense at være attributter (kolonner) af type; eller ikke. Et cetera.

Svar på kommentarer 30. november 10

.
Fremragende, du forstår dine data. Ret. Nu forstår jeg, hvorfor du havde en egenskabstabel.

1. Sørg for, at disse 10 eksempler er repræsentative, jeg ser nærmere på dem.

   • Type:Gem Name:Emberspark Pendant ... Eller er Neck Diverse en type?
   • Er Unique en ægte ItemType? Jeg tror ikke
   • Handling. Vis "Vend venligst tilbage til en sæsonarrangør"
   • Hvor er Attrinutes for AttackPower og HitRating ?
     .

2. Hvor mange forskellige typer varer (på 35.000) er der, ala mit produktklynge eksempel. En anden måde at stille det spørgsmål på er, hvor mange variationer der er. Jeg mener, meningsfuldt, ikke 3500 elementer ÷ 8 attributter?

3. Ændres item_attributes uden en udgivelse af s/w (f.eks. en ny Inner Strength egenskab) ?

4. pr. vare, hvilke attributter gentager (mere end én); indtil videre ser jeg kun Action ?

5. Det er et spil, så du har brug for en db, der er stram og meget hurtig, måske fuldt memory resident, ikke sandt. Ingen nuller. Ingen VAR noget. Korteste datatyper. Dupliker aldrig noget (Gentag ikke dig selv). Er du tilfreds med bits (booleaner) og vektorer?

6. Har du brug for nemt at oversætte disse regexes til SQL, eller er du tilfreds med et seriøst slog for hver (dvs. når du først får dem til at arbejde i SQL, er de ret stabile, og så roder du ikke med det, medmindre du finder en fejl ) (ingen sarkasme, seriøst spørgsmål) ?

   6.1 Eller måske er det omvendt:db'en er diskresident; du indlæser det i hukommelsen én gang; du kører regexes på det under gameplay; indimellem skriver til disk. Derfor er der ingen grund til at oversætte regexes til SQL?

Her er en datamodel af, hvor jeg er på vej hen, dette er slet ikke sikkert; det vil blive moduleret af dine svar. For at være klar:

• Sjette normalform er Rækken består af den primære nøgle og højst én egenskab.

• Jeg har tegnet (6.1) ikke (6), fordi dine data styrker min tro på, at du har brug for en ren 6NF Relationel database

• Min Produktklyngedatamodel , det bedre-end-EAV-eksempel, er 6NF, derefter Normaliseret igen (Ikke i normal form) af DataType, for at reducere antallet af tabeller, som du allerede har set. (EAV-folk går normalt efter et eller nogle få gigantiske borde.)

• Dette er lige 5NF, med kun de 2 tabeller til højre i 6NF.

Link til spildatamodel

Link til IDEF1X-notation for dem, der ikke er bekendt med Relational Modeling Standard.

Svar på redigering #2 05. december 10

1.1. Ok, rettet.

1.2. Så er IsUnique en Indicator (boolean) for Item.

1.3. Handling. Jeg forstår. Så hvor skal du opbevare det?

1.4. NeckMiscellaneous betyder, at varen er i begge kategorier af Neck og Misc . Det betyder to separate Item.Name=Emberspark Pendant , hver med en anden kategori.

.
2. og 5. Så du har brug for hurtig hurtig memory-resident db. Det er derfor, jeg prøver at få dig over linjen, væk fra GridLand, til RelationalLand.
.
3. Ok, vi forbliver med Fifth Normal Form, intet behov for 6NF eller produktklyngen (tabeller pr. datatype). Indtil videre er Values er alle heltal.
.
4. Jeg kan desuden se:Level , RequiredLevel , IsUnique , BindsPickedUp , BindsEquipped .
.
5. Bits er booleaner { 0 | 1}. Vektorer er nødvendige for (Relationelle) fremskrivninger. Vi kommer til dem senere.
.
6. Ok, du har forklaret, du oversætter ikke regulære udtryk til SQL. (Slog betyder hårdt arbejde).
7. Hvad er Category.ParentId? Forældrekategori? Det er ikke dukket op før.
.
8. Attribute.GeneratedId ?

Evaluer venligst datamodellen (opdateret). Jeg har et par kolonner mere, udover det du har i din. Hvis der er noget, du ikke forstår i datamodellen, så stil et specifikt spørgsmål. Du har læst notationsdokumentet, ikke?

Jeg har Action som en tabel med ItemAction holde Value :
Equip: increase attack power by 28 er Action.Name =Increase attack power by og ItemAction.Value =28.