[mysql] tabel opdelen in meerdere tabellen

[RSD]

Voor een soort van RPG heb ik 3 soorten gebruikers welke een paar overeenkomende eigenschappen hebben en een flink aantal andere eigenschappen hebben. Het idee is, is dat de 3 soorten gebruikers flink naar elkaar gaan zoeken (hiervoor worden queries gebruikt).

De eigenschappen die de 3 gebruikers hebben staan vast evenzo de mogelijke waarden van de eigenschappen. Per gebruiker kunnen de waarden van de eigenschappen wel aangepast worden.

Daarnaast is de gebruikersnaam uniek over het geheel heen.

Nu vroeg ik me af hoe ik dit het beste in een database kan gaan verwerken. Kan ik nu het beste 4 tabellen maken, dus:

user
- username
- email
- type (trol,ridder,heks)
- dorp

trol
- behaard 0,1
- snelheid 0,1,2,3,4
- etc...

ridder
- vechten 0,1,2,3,4,5
- sterkte 0,1,2,3
- etc..

heks
- vliegen 0,1
- spreuken 0,1,2,3
etc....

of kan ik dit beter alles in 1 tabel stoppen en dan de trol bijvoorbeeld bij eigenschappen die niet voor hem gelden op 0 zetten?

[Matis]

Verdiep je eens in Wikipedia: Database normalization

Kort door de boch: hoe meer tabellen hoe beter

[NMe]

Je weet wat normaliseren is? Want dat heb je hier dus niet gedaan.

[RSD]

Jah ik weet wat dat is, maar als ik bijvoorbeeld een grote query heb, dan lijkt me dat niet echt handig al die subtabellen, dan krijg ik wel 20 joins?

[Matis]

RSD schreef op zaterdag 05 maart 2011 @ 21:55:
Jah ik weet wat dat is, maar als ik bijvoorbeeld een grote query heb, dan lijkt me dat niet echt handig al die subtabellen,

Alles in één tabel frotten is wel handig

dan krijg ik wel 20 joins?

Ik zie het probleem niet? DB engines zijn daar heel erg handig mee.

[NMe]

RSD schreef op zaterdag 05 maart 2011 @ 21:55:
Jah ik weet wat dat is, maar als ik bijvoorbeeld een grote query heb, dan lijkt me dat niet echt handig al die subtabellen, dan krijg ik wel 20 joins?

Ja, want al die tienduizenden developers die verzonnen hebben en ondersteunen dat normaliseren in 99,5% van de gevallen het beste idee is, die hebben het allemaal mis?

Er zijn maar een paar gevallen waar normaliseren niet goed uitpakt, en daar ga je denormaliseren in de vierde en vijfde normaalvorm. Maar dat zijn doorgaans optimalisatiestappen en daar ben je nu, bij je ontwerp, waarschijnlijk nog helemaal niet aan toe.

En zelfs als je denormaliseert is je voorstel in de topicstart gewoon fout.

[Janoz]

Met "ga normaliseren" aan komen zetten is wel een beetje kort door de bocht. In principe loopt de topicstarter hier aan tegen de mismatch tussen een standaard relationele database aan de ene kant en een OO structuur aan de andere kant.

Er zijn inderdaad verschillende manieren om inheritance te mappen op een relationeel model. Elke heeft zijn voordelen en zijn nadelen. JPA heeft er drie:

SINGLE_TABLE
Alles zit in 1 tabel met waarschijnlijk ook veel NULL velden. ER wordt een 'discriminator' kolom opgenomen die aangeeft welk type het is. (het 'andere' voorstel van de TS). Dit is de standaard manier die JPA gebruikt wanneer je niks aangeeft.

TABLE_PER_CLASS
Elk type zit in een eigen tabel, inclusief alle generieke velden. Om op de generieke velden te zoeken wordt een UNION gebruikt.

JOINED
DIt lijkt op de uitgeschreven manier van de TS. Het complete object moet worden opgevraagd middels een join. Het enige verschil is dat er niet een type kolom in de user tabel zit, maar een id in de subclass tabellen zodat deze aan de superclass gejoined kunnen worden.

[ID-College]

Het gaat TS erom dat hij wss niet zo goed in SQL is en dus die queries niet voor elkaar krijgt.. Het is natuurlijk leuk, maar als je vrij basic met SQL overweg kan, dan is zoiets nauwelijks te realiseren...

[dusty]

Wat ga je doen als je over een jaar besluit dat je ook behaarde heksen hebt? of een type troll opeens vleugels heeft gekregen en kan vliegen?

Alle monsters dus netjes in een tabel stoppen, een heks heeft geen haren, dan komt daar natuurlijk netjes een 0 neer, zelfde voor elke andere monster, de user data hou je netjes in een aparte tabel

[RSD]

Hmm, nu weet k helemala niet meer wat ik moet doen. De een zegt normaliseren en de ander weer niet?

Ik ben nu bezig met:

attributeid
- id PK
- name

attributevalue
- id PK
- attributeid PK
- name

Maar moet ik zoiets als het geslacht of nieuwsbrief optie bijvoorbeeld hier nu ook inzetten, of kan ik dat beter in de user tabel zetten?

[ Voor 3% gewijzigd door RSD op 05-03-2011 22:44 ]

[Creepy]

Als je echt die kant op wil, sla alleen de attributen op die verschillend zijn voor al je monsters. Een naam bijv, zullen ze allemaal hebben, neem die dan ook echt als veld op, en niet ergens verstopt in je attributen tabel. Users moet je uberhaupt buiten dit verhaal laten, zoals dusty ook al aangeeft.

Persoonlijk zou ik ook de oplossing van dusty kiezen. Daarnaast denk ik dat als je de boel echt hebt uitgedacht het aantal verschillende attributen voor al je monsters niet eens zo heel groot is omdat er nogal wat overlap zal zijn.

[RSD]

Ik weet nu dus echt niet meer wat handig is. Een user kan zeg maar één type monster zijn. Een user kan dus niet meerdere monsters hebben. Een user is zeg maar een monster.

Ik heb dus de tabellen:
user
- id
- username
- creation_date
- newsletter
- gender enum (male,female)
- villageid

country
- id
- country

region
- id
- region
- countryid

village
- id
- village
- regionid

/* dit wordt ingevuld middels checkboxes, meerdere antwoorden per vraag mogelijk */
looking_for (bijv: Op zoek naar, Leeft in)
- id
- description

looking_for_value (Op zoek naar(trollen,heksen,ridders) Leeft in(hut,grot,kasteel) )
- id
- desciption
- looking_for_id

user_looking_for_value
- userid
- looking_for_value_id

/* eigenschappen van de beesten 1 mogelijkheid */
property (Gewicht,Lengte)
- id
- description

property_value(Gewicht (1 steen,2 stenen, etc) Lengte (1 grasspriet, 2 grassprieten, etc))
- id
- description
- property_id

user_property_value
- userid
-property_value_id

Waarschijnlijk kan ik die properties en lookingfors het beste samenvoegen, maar ik dacht omdat in de applicatie het twee verschillende zoek mogelijkheden worden ik ze het beste kan scheiden.

Evenzo met het locatie gebeuren, dit kan ik bijvoorbeeld ook in een property tabel zetten, maar het voelt niet goed omdat te doen. Waarom weet ik ook niet. Het is erg lastig om een redelijk model te krijgen. Zelf denk ik dat het het makkelijkste is om alles in 1 tabel te zetten, dus een platte tabel, maar met zoeken wordt het dan erg lastig. En gender, kan ik die bijvoorbeeld ook het beste daarin plaatsen?

[ Voor 5% gewijzigd door RSD op 06-03-2011 09:48 ]

[Remus]

Je realiseert je hoop ik wel dat als je zo met properties werkt, dat je feitelijk bezig bent om een database in een database te maken. Dat moet het moment zijn waarop je even stop, afstand neemt en je jezelf moet afvragen: 1) Is dit wel het juiste datamodel, 2) moet ik wel een SQL database gebruiken voor mijn probleem.

[Verwijderd]

Remus schreef op zondag 06 maart 2011 @ 11:18:
Je realiseert je hoop ik wel dat als je zo met properties werkt, dat je feitelijk bezig bent om een database in een database te maken. Dat moet het moment zijn waarop je even stop, afstand neemt en je jezelf moet afvragen: 1) Is dit wel het juiste datamodel, 2) moet ik wel een SQL database gebruiken voor mijn probleem.

Hoezo een database in een database? Ik zeg niet dat ik het 100% eens ben met het datamodel dat hij voorstelt in zijn laatste post, maar dan nog snap ik niet echt wat je bedoeld. Hij zit er wel iets naast zo te zien, maar het is IMHO niet de vraag of hij hier SQL voor moet gebruiken... Welke manier stel je dan voor om dynamische eigenschappen op te slaan?

[Verwijderd]

Verwijderd schreef op zondag 06 maart 2011 @ 15:29:

Welke manier stel je dan voor om dynamische eigenschappen op te slaan?

Zijn er in deze context dynamische eigenschappen dan? Ik denk namelijk van niet.

[RSD]

Maar wat is nu concreet het beste dan, elke eigenschap in een aparte tabel plaatsen en dan daar de mogelijke waarden inzetten en die dan koppelen met het id en voor eigenschappen die meerdere waarden kan bevatten een koppel tabel gebruiken, dus zoiets als:

user
- id
- username
- email
- gender_id (kan 1 waarde bevatten)
- village_id (kan maar 1 waarde bevatten)

gender
- id
- description

lives_in (user kan op meerdere plekken wonen)
- id
- description

user_lives_in (met deze tabel koppelen)
- id
- lives_in_id
- user_id

[NMe]

"lives in" is sowieso geen geschikte tabelnaam. Als je een tabel niet kan omschrijven met een zelfstandig naamwoord, dan is hij niet goed opgezet.

[RSD]

Het is even ter voorbeeld, ik gebruik deze namen ook niet, het is om het probleem te illustreren. Ik wist niet dat het netter was om alleen zelfstandignaamwoorden te gebruiken.

Maar goed, ik ben nog steeds niet veel verder.

Ik vraag me ook vaak af of het handig is om een index op een kolom te plaatsen die maar twee waarden kan bevatten. Zoals een index op bijvoorbeeld de kolom gender.

Ik meen eens gelezen te hebben dat het niet verstandig is, omdat je dan een grote index file gebruikt.

[ Voor 11% gewijzigd door RSD op 07-03-2011 12:02 ]