Een tip nodig over een eenvoudig MySQL db-ontwerp

Waarom heb je een attribute tafel ?

Attributen zijn kolommen, geen tabellen.

De websitelink zegt ons niets.

Het hele idee van een database is dat je de vele kleine tabellen samenvoegt, zoals vereist, voor elke query, dus daar moet je aan wennen. Natuurlijk, het geeft je een raster, maar een korte en zoete, zonder Nulls. Wat u probeert te doen, is tafels vermijden; ga met slechts één enorm raster, dat vol zit met nulls.

(knip)

Plaats uw attribuutnamen (kolomnamen) niet voor de tabelnaam, dat is overbodig. Dit zal u duidelijk worden wanneer u SQL gaat schrijven die meer dan één tabel gebruikt:dan kunt u de tabelnaam of een alias gebruiken als prefix voor kolomnamen die dubbelzinnig zijn.

De uitzondering is de PK, die volledig wordt weergegeven en in die vorm wordt gebruikt waar het een FK is.

Blader door de site en lees enkele SQL-vragen.

Nadat je dat gedaan hebt, kun je later bedenken of jestrength . wilt en defense om attributen (kolommen) te zijn van type; of niet. Et cetera.

Reacties op opmerkingen 30 november 10

.
Uitstekend, u begrijpt uw ​​gegevens. Rechts. Nu begrijp ik waarom je een attributentabel had.

1. Zorg ervoor dat die 10 voorbeelden representatief zijn, ik bekijk ze nauwkeurig.

   • Type:Gem Naam:Emberspark Hanger ... Of is NeckMiscellaneous een type?
   • Is Unique een echt ItemType? Ik denk niet
   • Action.Display "Gelieve terug te keren naar een seizoensorganisator"
   • Waar zijn de attributen voor AttackPower en HitRating ?
     .

2. Hoeveel verschillende soorten artikelen (van 35.000) zijn er, ala mijn Product Cluster voorbeeld. Een andere manier om die vraag te stellen is hoeveel variaties er zijn. Ik bedoel, zinvol, niet 3500 items ÷ 8 attributen ?

3. Zullen de item_attributes veranderen zonder een release van s/w (bijv. een nieuwe Inner Strength attribuut)?

4. Per item, welke attributen herhalen (meer dan één); tot nu toe zie ik alleen Actie ?

5. Het is een spel, dus je hebt een db nodig die strak en erg snel is, misschien volledig in het geheugen, toch. Geen nul. Geen VAR iets. Kortste gegevenstypen. Dupliceer nooit iets (herhaal jezelf niet). Ben je tevreden met bits (booleans) en vectoren?

6. Moet je die regexes gemakkelijk naar SQL vertalen, of ben je blij met een serieuze slog voor elk (dwz als je ze eenmaal in SQL hebt laten werken, zijn ze behoorlijk stabiel en dan knoei je er niet mee, tenzij je een bug vindt ) (geen sarcasme, serieuze vraag) ?

   6.1 Of misschien is het andersom:de db is schijfresident; je laadt het eenmaal in het geheugen; je voert de regexes daarop uit tijdens het spelen; af en toe schrijven naar schijf. Daarom is het niet nodig om de regexes naar SQL te vertalen?

Hier is een gegevensmodel van waar ik naartoe ga, dit is helemaal niet zeker; het zal worden gemoduleerd door uw antwoorden. Voor de duidelijkheid:

• Zesde normaalvorm is De rij bestaat uit de primaire sleutel en maximaal één kenmerk.

• Ik heb (6.1) niet (6) getekend, omdat je gegevens mijn overtuiging versterken dat je een pure 6NF relationele database nodig hebt

• Mijn Productclustergegevensmodel , het beter-dan-EAV-voorbeeld, is 6NF en vervolgens opnieuw genormaliseerd (niet in de zin van de normale vorm) door DataType, om het aantal tabellen te verminderen, dat u al hebt gezien. (EAV-mensen gaan meestal voor een of een paar gigantische tafels.)

• Dit is rechtstreeks 5NF, met alleen de 2 tafels aan de rechterkant in 6NF.

Link naar spelgegevensmodel

Link naar IDEF1X-notatie voor degenen die niet bekend zijn met de Relational Modeling Standard.

Reactie op Edit #2 05 Dec 10

1.1. Oké, gecorrigeerd.

1.2. Dan is IsUnique een indicator (boolean) voor item.

1.3. Actie. Ik begrijp. Dus waar ga je het opslaan?

1.4. NeckMiscellaneous betekent dat het item zich in beide categorieën van Neck bevindt en Misc . Dat betekent twee aparte Item.Name=Emberspark Pendant , elk met een andere categorie.

.
2. en 5. Je hebt dus wel een snelle snelle geheugenresidente db nodig. Daarom probeer ik je over de streep te krijgen, weg van GridLand, naar RelationalLand.
.
3. Ok, we blijven bij de vijfde normaalvorm, geen behoefte aan 6NF of het productcluster (tabellen per datatype). Tot de Values zijn allemaal gehele getallen.
.
4. Ik kan bovendien zien:Level , RequiredLevel , IsUnique , BindsPickedUp , BindsEquipped .
.
5. Bits zijn booleans { 0 | 1 }. Vectoren zijn vereist voor (relationele) projecties. We komen er later op terug.
.
6. Ok, je hebt het uitgelegd, je vertaalt geen reguliere expressies naar SQL. (Slog betekent hard werken)..
7. Wat is Category.ParentId? Ouder categorie? Dat is nog niet eerder naar voren gekomen.
.
8. Attribuut.GeneratedId ?

Evalueer het gegevensmodel (bijgewerkt). Ik heb nog een paar kolommen, naast wat je in de jouwe hebt. Als er iets is dat u niet begrijpt in het gegevensmodel, stel dan een specifieke vraag. Je hebt het notatiedocument gelezen, toch?

Ik heb Action als een tabel, met ItemAction met de Value :
Equip: increase attack power by 28 is Action.Name =Increase attack power by en ItemAction.Value =28.