database model

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Veur Heur

Veur Heur

17/03/2019 15:01:40
Quote Anchor link
Ik heb een tik en dat is pretparken en dan met name achtbanen. Deze tik is overgeslagen op mijn dochter en ik ben dan ook een hobby projectje begonnen waarin ik bijhoud welke achtbanen we berijden, wanneer en hoeveel keer. Hiervoor heb ik het volgende model (vereenvoudigd):

- 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.
 
PHP hulp

PHP hulp

22/04/2019 23:02:38
Honeypot
 
Martin de Schrijver

Martin de Schrijver

17/03/2019 16:58:47
Quote Anchor link
Dit is een typisch geval voor een JOIN TABLE.

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!
 
Veur Heur

Veur Heur

17/03/2019 17:25:56
Quote Anchor link
Dank voor deze duidelijke uitleg. Hier heb ik bij mijn opzet overheen gestapt door de relatie in de achtbaan tabel te leggen. Hierdoor is een meer op meer relatie niet mogelijk.

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.
 
Thomas van den Heuvel

Thomas van den Heuvel

17/03/2019 17:35:19
Quote Anchor link
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
 
Veur Heur

Veur Heur

17/03/2019 17:41:19
Quote Anchor link
Dat is ook geen verkeerde aanvliegroute Thomas.
 
Thomas van den Heuvel

Thomas van den Heuvel

17/03/2019 17:41:53
Quote Anchor link
Lijkt mij het simpelst :).
 
Veur Heur

Veur Heur

17/03/2019 20:02:37
Quote Anchor link
Thanks voor jullie inzicht! Ik heb het nodige gewijzigd in mijn database en met wat aanpassingen in mijn queries heb ik nu de aangepaste overzichten waar ik naar op zoek was.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.