Databasemodel voor tennistrainingen en de inschrijving

[Scott]

Sinds een paar jaar onderhoud ik de website voor het inschrijven en verwerken van alle tennissers van de club waar ik lid van ben. Dit komt neer op: zorgen dat er ingeschreven kan worden en dat alle benodigde informatie opgeslagen werd. Deze informatie kon per seizoen (er is een zomer- en winterseizoen) verschillen. Nu zit ik in 6 VWO en weet ik niet zeker of ik daar nog mee door kan gaan volgend jaar, in verband met een vervolgopleiding. Ik heb daarom besloten om een script te maken die elk seizoen opnieuw te gebruiken is. Het databasemodel ziet er als volgt uit:



Omdat het natuurlijk zonder uitleg niet echt te begrijpen is, hier in het kort hoe het systeem eruit zou moeten gaan zien.

Het is dus voor de gebruikers nodig dat er elk seizoen een inschrijfformulier op de site komt, met een aantal velden. Deze velden kunnen elk jaar variabel zijn, vandaar een tabel `velden`. In de tabel formulieren worden de velden aan elkaar gekoppeld per seizoen. Elk seizoen heeft dus een eigen record in `formulieren` (of, als het formulier identiek is aan een ander seizoen, dan kan er natuurlijk 1 record gebruikt worden voor beide seizoenen).

Je hebt natuurlijk te maken met trainers en bij het inschrijven kan het zijn dat er op een gegeven moment gezegd wordt (door degene die dit alles leidt) dat er een voorkeur voor trainer aangegeven mag worden. Dus er moet ook een tabel `trainers` zijn.

Uiteindelijk wordt alle informatie die door een tennisser wordt ingevuld opgeslagen in de tabel `inschrijvingen`. Hoe ik dit moet gaan doen (rekeninhoudend met dat die informatie kan verschillen per seizoen) weet ik nog niet, dus als er iemand een tip of suggestie heeft: graag!

`inschrijvingen` wordt in principe niet geleegd omdat de inschrijvingen voor seizoen 2 al beginnen terwijl seizoen 1 nog bezig is en de mensen die zich hebben opgegeven voor de training van seizoen 1 nog wel na moeten kunnen kijken in welk groepje ze trainen, op welke dag, hoe laat, bij welke trainer enz. (Daar komt ook de tabel `groepjes` vandaan.)

Omdat die tabel dus nooit geleegd wordt, leek het me handig een tabel `leden` te maken, om zo redundantie te voorkomen in `inschrijvingen`.

Dan als laatste is er nog de tabel `roosters` en zoals je ziet is deze gekoppeld aan `seizoen`. Dit omdat de mógelijke trainingstijden van seizoen tot seizoen kunnen veranderen.

Ik hoop dat ik wat duidelijkheid gebracht heb in wat ik wil. Mijn eigenlijke vraag is nu: is dit databasemodel goed of kan er nog het een en ander aan verbeterd worden (en wat dan) ?

[asfaloth_arwen]

Begin eens met definieren wat je op wilt nemen in je database. Vervolgens in de juiste tabel plaatsen. (Dus ook in je database model, dan krijg je een veel duidelijker beeld). Leg ook PK's/FK's indexen e.d. vast.

[ Voor 36% gewijzigd door asfaloth_arwen op 29-11-2007 19:50 ]

[Scott]

Sorry voor mijn late reactie, maar als tijd te koop was had ik vrachtwagens vol gekocht

Anyway, ik heb je raad opgevolgd en ben hem wat verder uit gaan werken. Uiteindelijk is het dit geworden:

Een paar vraagjes die ik nog wel heb:

1) In bijvoorbeeld de tabel trainers heeft het veld ID automatisch al een index, maar eigenlijk moet het enige andere veld 'name' ook een index hebben. Is dit handig om te doen en moet ik hem dan bij de PRIMARY-index zetten of een nieuwe index maken (alleen voor dat ene veld) ?

2) Als je je inschrijft kun je een voorkeur en een 'afkeur' (dagen/tijden waarop je echt niet kan) opgeven. Deze heb ik nu in één tabel gezet waarbij het veld 'mode' aangeeft of het om een voor- of afkeur gaat. Wat is beter, de manier zoals ik het nu heb gedaan, of twee tabellen; één met voorkeuren en één met afkeuren ?

3) En eigenlijk zit ik nog steeds met de vraag hoe ik de waardes van custom fields (die dus in de database zijn opgeslagen) op ga slaan. Ik kan een simpele koppeltabel laten werken, maar als je 15 custom fields hebt, 200 inschrijvingen per seizoen, en 3 seizoenen verder bent zit je dus algauw op 15 × 200 × 3 = 9000 records. Nou weet ik wel dat MySQL (want daar moet het uiteindelijk op komen te draaien) dat wel aankan, maar misschien dat er iemand een makkelijkere manier heeft ?


Verder nog een kleine notitie: omdat dit de eerste keer is dat ik een groot project opzet, is dit ook voor het eerst dat ik gebruik maak van indexen en PK's & FK's (ik moest zelfs even nadenken over wat je daarmee bedoelde asfaloth_arwen ), dus wellicht dat ik daar denkfouten heb gemaakt.

Ik hoor graag jullie reacties, op- en aanmerkingen!

[BikkelZ]

Dit lijkt wel mijn databases boek van de HvU van vroeger. Ging ook altijd maar weer over die tennisvereniging.

*gaap*

[Scott]

Haha ja, ik kreeg bij informatica vorig jaar (5V) ook inderdaad de tennisvereniging. Dit is echter wel een iets ander verhaal denk ik..

Verder niemand die er iets over heeft te zeggen ?

[BikkelZ]

Seasons

DATE datatype voor seizoensstart
DATE datatype voor seizoenseinde

Nu hoef je in registrations alleen maar een datum bij te houden (ook DATE gebruiken) en dan kun je met de ingebouwde datumfuncties van je database kijken in welk seizoen het valt. Scheelt je een hoop tabellen en het programmeert veel natuurlijker.

[Scott]

Dat klinkt erg handig! Ik moet wel rekening houden met één ding: er kunnen inschrijvingen komen voor de junioren en senioren (bij ons op de club). Ik had bedacht om voor beide een record aan te maken (bijv. Wintertraining senioren 2008 en Wintertraining junioren 2008), maar op deze manier kan dat niet meer.

Waarom niet ? Er wordt niet bijgehouden waarvoor er wordt ingeschreven. Een extra veld maken en daarin bijhouden of het een senior of junior is zou kunnen, maar mocht ik het allemaal af hebben en het werkt allemaal goed, dan wil ik het misschien gaan verkopen aan andere clubs ook. Als die dan geen onderscheid maken tussen junioren en senioren, dan moet ik het script weer aanpassen. Ik houd het het liefst dus zo variabel mogelijk.

[BikkelZ]

NOOIT aparte tabellen maken op die manier.

Junioren en Senioren, je zou ook kunnen zeggen dat je een leeftijdsgroep maakt. Als die bij sommige clubs gewoon standaard 1 ("Alle leeftijden") is en je verbergt het veldje waar je dat normaal in ziet, ben je veel en veel sneller klaar bij een andere club.

Het is een eigenschap van dat lid. Dus je kunt via het id van het lid achterhalen wat zich heeft ingeschreven of het een junior of een senior is. Alleen ben jij bang om joins over meerdere tabellen te doen, en daar hoef je niet bang voor te zijn, dat werkt in de praktijk erg makkelijk.

Je bent nu eigenschappen van een datum (seizoen) en eigenschappen van een lid (senior / junior) aan het verwarren met tijdstippen. Als je nou speciale trainingen hebt voor junioren en senioren, dan matchen die weer naar de zelfde tabel waar de leden ook aan gekoppeld zijn.

ALTIJD compleet normaliseren.

Krijg je geen spijt van, geloof me.

[ Voor 46% gewijzigd door BikkelZ op 07-12-2007 09:41 ]

[Scott]

BikkelZ schreef op vrijdag 07 december 2007 @ 09:38:
Het is een eigenschap van dat lid. Dus je kunt via het id van het lid achterhalen wat zich heeft ingeschreven of het een junior of een senior is. Alleen ben jij bang om joins over meerdere tabellen te doen, en daar hoef je niet bang voor te zijn, dat werkt in de praktijk erg makkelijk.

Ik ben niet echt bang voor die JOINS, 't is meer dat ik niet weet hoe ik zou moeten achterhalen of een lid een senior of junior is. Als de geboortedatum niet per se ingevuld hoeft te worden (dat zou kunnen, als de mensen die het indelen die niet nodig hebben), dan weet je nooit of die persoon in de senioren of junioren valt..

Of begrijp ik je gewoon verkeerd ?

[BikkelZ]

Senior of junior is een classificatie, zeg dat je iemand van 17 of 18 hebt dat die dan mag kiezen waar die bij speelt.

[BikkelZ]

Table LidType

- id
- lidtype (junior of senior)

Table lid:
- Naam
- Gebdat
- enz.
- lidtype_id

[Scott]

Ik zet het dan wel bij de registrations-tabel (een lid kan immers nu wel junior zijn, maar volgend jaar senior), maar je punt is duidelijk

Nu ik nog eens zo zit te kijken zie ik eigenlijk niet welke tabellen dit me zal schelen (terwijl ik het gister nog wel zag ). Ik heb elke tabel bekeken, maar ik geloof dat ik elke tabel die in dat schema staat nog wel nodig is... Is, denk ik, ook wel te verklaren: het veld seasons_id vervalt en in de plaats daarvan komt registration_date. Waar eerst een inschrijving en een seizoen aan elkaar gekoppeld waren aan de hand van id's, wordt dit nu met datums gedaan.

Je zal best gelijk hebben, zie nu alleen even niet zo waarom

[BikkelZ]

Jij ziet een tijdstip als een op zichzelf staand ding, terwijl het een eigenschap is.

[Scott]

Zou je dat misschien iets meer toe kunnen lichten ? Waarvan is het bijvoorbeeld een eigenschap ? En hoe zal dit leiden tot een vermindering van tabellen ?

[BikkelZ]

Nou die drie timetable objecten kun je volgens mij allemaal verwijderen, een season heeft gewoon een begin en een einddatum. Je hoeft alleen maar bij te houden wanneer een registratie is gedaan om te zien in welke season die valt.

[Scott]

De functie van de timetable is anders dan wat jij denkt, denk ik. Als speler kun je aangeven wanneer je absoluut niet kan en welke dag en tijd je voorkeur heeft. Deze tijden zonder onderverdeeld in blokken (bijv. ma van 13:00 to 15:00, ma van 15:00 tot 17:00). Deze blokken moeten allemaal onder elkaar komen en de gebruiker moet dan aangeven wat zijn voorkeur en wanneer hij/zij absoluut niet kan. De timetable heeft dus vrij weinig te maken met de registratie per seizoen.

Deze tijdsblokken kunnen verschillen per seizoen (vandaar seasons_timetable) en moeten aan spelers gekoppeld worden (registrations_timetable).

[BikkelZ]

Dan hoeft er nog steeds geen koppeltabel gebruikt te worden, alleen maar tussen speler(s) en tijdvak.

[Scott]

Volgens mij niet, zie de volgende situatie:

In een zomerseizoen heeft de club bijvoorbeeld banen van 13:00 tot 19:00. Dan kun je blokken hebben van 13:00 tot 15:00, van 15:00 tot 17:00 en van 17:00 tot 19:00.
In een winterseizoen heeft de club banen van 14:00 tot 18:00. Dan kun je maar twee blokken hebben: 14:00 tot 16:00 en van 16:00 tot 18:00.

De tijdblokken verschillen dus per seizoen en bij het inschrijven moet er een keuze gemaakt worden (voorkeur en 'afkeur') bij het inschrijven. De blokken die bij dat seizoen horen moeten dan wel getoond worden, iets dat volgens mij alleen maar kan op de manier zoals ik het nu heb (met een koppeltabel). Een DATE meegeven aan de blokken zou kunnen, maar als je voor elk zomerseizoen dezelfde blokken gebruikt, zit je al met dubbele records.