Fabio BrunaNotities, boeken, films, Haags spul.

Het datamodel van de squashcompetie heeft wel zo’n beetje zijn uiteindelijke vorm gekregen. Nu de individuele tabellen met attributen. Eerst de spelerstabel. Een belangrijke tabel, maar hij blijft redelijk eenvoudig.
De naam van de tabel is in enkelvoud. Niet om een speciale reden, maar voor de duidelijkheid kies ik voor enkelvoud in de tabelnamen.
De tabel krijgt een betekenisloze sleutel, de ID zodat we uniek kunnen verwijzen naar 1 speler. Dit veld wijzigt nooit en wordt door het systeem gegenereerd.
Spelers zullen moet inloggen, en met een zelfgekozen inlognaam. Dit is verplicht in te vullen veld dat niet wijzigt.
Bij die naam hoort een wachtwoord. Ook verplicht, maar deze mag een speler wel wijzigen.
Dan is er nog een attribuut ‘name’. Dit is de naam waarmee iemand in het systeem zichtbaar is bij commentaren etc. Kan dus iets anders zijn dan de inlognaam.
Een e-mailadres is ook verplicht. O.a. omdat iemand zijn wachtwoord kan vergeten, en een nieuw wachtwoord sturen we naar het e-mailadres.
Dan volgt er een e-mail vlag. Iemand kan aangeven dat hij bijvoorbeeld de standenmail wel of niet wil ontvangen. Dit onderdeel moet ik nog iets meer uitwerken, misschien zijn meer vlaggen nodig.

Vandaag weer wat meters geprobeerd te maken met het squash script.
Eerst de issue tracker geschikt gemaakt voor ‘misbruik’ als wensen-indexeer-middel.
En gewerkt aan het datamodel. Tijdens dat werk kwam ik er achter dat DBdesigner al een tijdje obsolete is, inmiddels kennelijk is opgekocht door MySQL(?) en MySQL workbench heet. Geeft maar weer helemaal aan hoe scherp ik op de nieuwste ontwikkelingen in mijn werk let ;-(
Anyway, MySQL workbench is net zo’n prachtige naam als DBdesigner en doet gewoon hetzelfde. Weer aan de slag dus.
Ik denk vast snel te technisch, maar doe toch een poging losse entiteiten te onderscheiden in het systeem van een squash competitie.

• Speler. Lijkt mij een heldere entiteit in dit model.
• Een wedstrijd. Idem
• Een competitie. Een groep spelers besluiten tot een competitie. Meerder competities moeten mogelijk zijn, en wel of niet zichtbaar voor anderen etc.
• Een ranglijst. De betekenis in de werkelijkheid is helder, ik noem ‘m als een aparte entiteit en niet als relatie tussen zeg wedstrijd-competitie-speler omdat we hier ook de geschiedenis vasthouden en dus een ‘statistiek’ achtige pagina krijgen. Moet nog worden uitgewerkt(zoals alles overigens).
• Discussie. Voorlopig vaag, maar de discussie zet ik toch even apart op de kaart. Misschien komt er later een goede reden voor. Of niet, en dat verdwijnt ‘ie direct weer.

Dan de relaties. Er zijn 2 n:n(veel op veel) relaties.

Een speler kan speler in meerdere competities.
Een competitie zal logischerwijs meerdere spelers bevatten.

Een speler zal logischerwijs meerdere matches spelen.
Een match heeft altijd twee spelers.

Om dat op te lossen zal ik twee tussentabellen moet maken die verwijzende sleutels tussen deze tabellen bevatten. Een tabel members_has_competitions(rel_01 en rel_02) en een tabel members_has_games(rel_04 + rel_05).

De rest is 1:n(een op meer) relaties:

De ranglijst hangt aan een competitie(rel_09). Mijn idee is dat discussies ook aan een competitie kunnen hangen, dus die koppel ik er ook aan.
Discussies hangen primair aan een match(rel_07), maar ook aan een ranglijst(rel_10). Discussies hebben altijd een speler als oorsprong(rel_08).

Attributen van de losse entiteiten komen later wel. Eerst het model goed krijgen. Genoeg om op te kauwen de komende week.