Voordat ik naar een oplossing kan kijken, eerst een paar 'zaken van algemeen nut'. Zo constateer ik al gelijk dat je tabellen niet gekoppeld zijn. Zo zouden de tabellen [1 tabel jongeren] en [2 tabel vrijwilligers] gekoppeld moeten worden aan [6 matches], maar dat is nog niet gebeurd. Kán ook niet, want als je dat probeert, krijg je een foutmelding
. Er blijkt geen Referentiële integriteit te zijn tussen de koppelvelden, en dat is een stuk kwalijker dan dat de tabellen niet gekoppeld zijn. Dat laatste kun je namelijk met stricte regels op je formulieren nog wel ondervangen. Ga je in de tabellen kijken, dan blijkt er in [6 matches] een record te zitten met een waarde 0 in het veld [id jongere], en dat kan dus inderdaad niet: die waarde heb je niet (en zul je ook nooit hebben) in [1 tabel jongeren]. Het is een goede zaak om, voordat je records gaat invullen, eerst de relaties te leggen tussen de tabellen, dan kan dit niet gebeuren.
Volgende wat ik zou aanpassen: je gebruikt in het veld [aanmelding: naam verwijzer] een dubbele punt in de naam. Hoewel dat wel mag (anders had je het veld niet kunnen maken) is dat erg onhandig, want een dubbele punt is een gereserveerd teken in een database, en je kunt daar problemen mee krijgen later. Probeer die dubbele punt dus in namen te vermijden. Sowieso gebruik je érg lange veldnamen, en dat is, hoewel dus niet verboden, niet handig. Probeer veldnamen kort en bondig te houden, maar wel beschrijvend en liefst zonder spaties (nog zo'n teken waar je later problemen mee kan krijgen).
Daarnaast gebruik je voor het veld [aanmelding: naam verwijzer] een keuzelijst als invoer. Niet doen. Keuzelijsten die je baseert op een lijst met velden, zoals [wettelijk vertegenwoordiger2: soort] zijn prima (behalve dus naam, gebruikte tekens en lengte) maar een keuzelijst moet je niet baseren op een tabel, hoe handig Microsof je dat ook voorschotelt. In een tabel wil je
altijd de opgeslagen waarden zien, en dat doe je nu dus niet. Je kunt dus ook nooit goed filteren op dat veld, want je hebt geen flauw benul wat je als filter moet invullen. In ieder geval
niet wat je in het veld ziet staan! Keuzelijsten (met invoervak)
moet je alleen op formulieren gebruiken! Nogmaals: als ze zijn gebaseerd op tabellen.
Het belangrijkste heb ik voor het laatst bewaard: je database is niet goed genormaliseerd. En dat kun je al zien aan een veld als [wettelijk vertegenwoordiger2: soort]. Je hebt namelijk óók de velden [wettelijk vertegenwoordiger1: naam], [wettelijk vertegenwoordiger1 soort], [wettelijk vertegenwoodiger1: telefoon 1] [wettelijk vertegenwoodiger1: telefoon 2] en [wettelijk vertegenwoodiger1: bereikbaarheid]. En dat dus * 2, want je doet dit voor 2 vertegenwoordigers. Dit roept allerlei problemen op. Het begint er al mee dat je maar 2 vertegenwoordigers kunt invoeren. Stel dat je ooit de behoefte krijgt aan een derde persoon, waar laat je die dan? Weer extra velden toevoegen? Nee, dat is niet de oplossing.
Volgende probleem dat op de loer ligt: als bij 3 jongeren dezelfde wettelijke vertegenwoordiger is benoemd, dan moet je voor alle personen in elk record dezelfde gegevens invoeren. Maar is de persoon 'Michael Stradivarius' dezelfde persoon als 'Michel Stradivarius' of 'Michael Stradievarius'? Wie het weet mag het zeggen... En je mag er toch vanuit gaan dat één persoon wel dezelfde telefoonnummers zal gebruiken. Of geef je die persoon bij elke nieuwe koppeling 2 nieuwe telefoons? Kortom: voor de vertegenwoordigers heb je een aparte tabel nodig, waarin je een VertegenwoordigerID als sleutelveld hebt, en waarin je alle velden zet die nu in [1 tabel jongeren] staan. Je verwijdert dus alle 10 velden, en je maakt een koppeltabel met daarin een verwijzing naar [Jongeren] en [Vertegenwoordigers] op basis van de sleutelvelden, en dan heb je deze situatie opgelost. Niet alleen kun je nu onbeperkt vertegenwoordigers loslaten op een persoon, je hoeft de gegevens ook niet meer elke keer opnieuw in te vullen.
Een vergelijkbaar probleem heb je in [3 tabel verwijzers] waarin je alle contactpersonen herhaalt. Dus die kun je op dezelfde manier opschonen. Ik zou overigens voor deze actie één tabel maken, waarin je alle personen zet met een extra veld wat de betreffende functie van de persoon is. Een mens is namelijk, ongeacht wat-ie doet, altijd een persoon met dezelfde soort gegevens (naam, telefoon, email etc). Dus dat mag je best in één tabel stoppen. Als iemand meerdere petten heeft, en dat vaker voorkomt zou ik het overigens gescheiden houden, al zou je nog een veld met meerdere waarden kunnen overwegen.
Genoeg huiswerk?
