database model
- pretparken: pretparkid, pretpark
- achtbanen: achtbaanid, pretparkid, achtbaan
- ritten: ritid, achtbaanid, datum, aantal
So far, so good, met dit model kan ik namelijk alles kwijt. Echter...
We bezoeken ook kermissen waar achtbanen dus reizen en ook willen achtbanen nog wel eens verkocht worden aan een ander park. Met andere woorden: er komt een tijd (is er nu eigenlijk al) waarop we dezelfde achtbaan berijden, echter staat deze op een andere locatie. Ik wil deze dan ook niet als uniek tellen. En ik wil deze in mijn overzichten ook graag tonen onder de andere locatie. Pretpark of kermis is in mijn overzichten overigens gelijk, echter zie ik dan aan de naam dat het een kermis was. Hier maak ik verder geen punt van.
Ik had zelf een extra tabel bedacht:
- ritid_pretparkid: ritid, pretparkid
In deze tabel registreer ik dan dat een vervolgrit heeft plaatsgevonden in een ander pretpark.
Is dit een logische denkwijze of zouden jullie zoiets (of het geheel) anders aanpakken? Een en ander is al best even in gebruik (mevrouwtje is 6 en heeft al bijna 100 unieke achtbanen gelogd, met vorig jaar alleen al zo'n 200 ritten en voor dit jaar staan er zo'n 90 banen op de planning), dus een geheel ander datamodel zou een hoop extra werk met zich meebrengen. Het is ook zo gegroeid. Waar ik eerst alleen bijhield welk pretpark, achtbaan en datum (de eerste rit), ben ik dus nu veel meer aan het loggen. Toen ben ik dan ook overgestapt van Excel naar MySQL.
Het is voor elke database heel erg belangrijk dat je het principe van een JOIN TABLE leert begrijpen.
Het gaat er hierbij om dat je leert wat één op meer en meer op meer relaties zijn.
Eén lokatie kan meerde achtbanen hebben
Eén achtbaan kan op meerdere lokaties staan
De relatie tussen de tabel lokatie en achtbaan is dus een meer op meer relatie!
Met een JOIN TABLE vermijd je die meer op meer relatie.
In de JOIN TABLE maak je voor iedere achtbaan een record met een lokatie
Wanneer de achtbaan verhuist naar een andere lokatie dan voeg je die toe in de JOIN TABLE
Je hebt bijv achtbaan Phyton en de Tornado
En de lokaties de Efteling en Hellendoorn.
De volgende opzet kan je hiervoor gebruiken
Tabel_achtbaan
achtbaan_id (primary key)
achtbaan_naam
twee records
achtbaan_id=1, achtbaan_naam=Phyton
achtbaan_id=2, achtbaan_naam=Tornado
Tabel_lokatie
lokatie_id (primary key)
lokatie_naam
twee records
lokatie_id=1, lokatie_naam=Efteling
lokatie_id=2, lokatie_naam=Hellendoorn
Tabel_achtbaan_line_items (de JOIN TABLE)
jointable_achtbaan_id (primary key)
achtbaan_idfk (foreign key)
lokatie_idfk (foreign key)
twee records
jointable_achtbaan_id=1, achtbaan_idfk=1, lokatie_idfk=1 (de Phyton in de Efteling)
jointable_achtbaan_id=2, achtbaan_idfk=2, lokatie_idfk=2 (de Tornado in Hellendoorn)
en als de Phyton van de Efteling naar Hellendoorn verhuist
jointable_achtbaan_id=3, achtbaan_idfk=1, lokatie_idfk=2 (de Phyton in Hellendoorn)
Tabel_ritten
tabel_ritten_id (primary key)
achtbaan_idfk (foreign key)
lokatie_idfk (foreign key)
Nu voeg je de ritten toe
vijf records
tabel_ritten_id=1, jointable_achtbaan_id=1 (de Phyton in de Efteling)
tabel_ritten_id=2, jjointable_achtbaan_id=1 (de Phyton in de Efteling)
tabel_ritten_id=3, jjointable_achtbaan_id=2 (de Tornado in Hellendoorn)
tabel_ritten_id=4, jjointable_achtbaan_id=2 (de Tornado in Hellendoorn)
tabel_ritten_id=5, jjointable_achtbaan_id=3 (de Phyton in Hellendoorn)
In dit geval zou je dus twee keer de Phyton gereden hebben in de Efteling.
Twee ritten in de Tornado in Hellendoorn.
Eén rit in de Phyton in Hellendoorn.
Nogmaals.
Het is heel belangrijk dat je het principe van één op meer en meer op meer relaties leert begrijpen!
Ik ga eens kijken of ik het de moeite vind om het nodige aan te passen of dat ik kermisbanen maar gewoon 1x tel, deze komen over het geheel genomen toch het minst voor.
Martin Puk op 17/03/2019 16:58:47:
Eén achtbaan kan op meerdere lokaties staan
Dit is niet helemaal waar. Op enig moment staat een achtbaan (het fysieke ding) maar op één locatie. Het kan wel zo zijn dat over tijd de locatie verandert. Oftewel, deze rechtstreeks vastleggen in achtbanen.pretparkid is niet verstandig, want dan kan de rit die je in de Efteling had na verloop van tijd ineens in Hellendoorn hebben plaatsgevonden, en dat is natuurlijk een stukje geschiedenisvervalsing.
Ik denk dat het oorspronkelijke idee van @Ves helemaal niet zo gek is maar in wezen heb je helemaal geen aparte tabel nodig, je zou het pretparkid kunnen weghalen bij de achtbaan (omdat deze blijkbaar niet vastligt) en kunnen toevoegen in ritten. De tabel ritid_pretparkid kan komen te vervallen dan. In principe is dat een minimale set aan data; de "ritten" tabel bevat nu een ovezicht van concrete real life ervaringen: Op <datum> zijn wij <aantal ritten> keer in de <achtbaan> geweest in het pretpark/de kermis <locatie>.
Pas op het moment dat je over tijd precies wilt bijhouden waar een achtbaan zich fysiek bevindt en dat je hier je ritten aan wilt hangen dan wordt het natuurlijk een compleet ander verhaal, maar voor nu lijkt mij het ontkoppelen van een achtbaan en een pretpark en het pretpark toevoegen aan de concrete rit afdoende.
edit: je zou natuurlijk wel aan de achtbaan een "locatie" veld "huidige standplaats" kunnen toevoegen ofzo, maar de ritten hier niet vanaf laten hangen uiteraard.
Gewijzigd op 17/03/2019 17:38:02 door Thomas van den Heuvel