Gebruikers laten 'rommelen' is uiteraard uit den boze
. Als ik het voor het zeggen had bij de ontwikkelafdeling van Microsof, dan zouden er een hoop onzinnige functies uit Access verdwijnen, kan ik je zeggen! M. wil (vermoed ik althans) dat
alle pakketten die ze leveren door
alle (al dan niet geschoolde) gebruikers moeten worden gebruikt. Dat werkt prima bij applicaties als Outlook, PowerPoint, Word en desnoods Excel, maar dus
niet voor Access. Het bouwen van een database vereist nu eenmaal onderliggende kennis die het programma niet voorziet. Dat concentreren op
gebruikersgemak leidt er dus toe dat er allerlei onzin in het pakket wordt ingebouwd, en geeft een nietsvermoedende gebruiker al snel de indruk dat hij/zij 'best een database kan bouwen'.
Dat gezegd hebbende, is het dus belangrijk om als bouwer goed inzicht te hebben in hoe een database wordt opgebouwd, en waarom je bepaalde dingen
niet moet doen, en andere dingen juist weer wel. Je bent, als ik je berichtjes zo lees, al redelijk goed bezig, want je hebt inzicht in
herhalende gegevens. En je bent begonnen om die apart te zetten in eigen tabellen. Ik vermoed dat je tabel [tPlaatsnamen] een veld [Plaatsnaam] heeft, misschien een veld [Gemeente], en een veld [PlaatsnaamID]. Wellicht werk je landelijk en heb je ook nog een veld [ProvincieID] (en dan dus ook een tabel [tProvincies]). In de tabel [tKlanten] heb je dan een veld [PlaatsnaamID] zodat je plaats en klant kunt koppelen. Gaat het om veel klanten, dan kun je wellicht nog overstappen op een koppeling met een Postcodetabel, want nu zit je in [tKlanten] vermoedelijk nog met niet-genormaliseerde straatnamen. En dat levert doorgaans nog meer ellende op dan Plaatsnamen
.
Laten we ons echter beperken tot Plaatsnaam en Klant, want de structuur van verdere opsplitsing is toch hetzelfde. De tabellen [tKlanten] en [tPlaatsnamen] moet je in het scherm <Relaties. aan elkaar koppelen op basis van het veld [PlaatsnaamID]. Daarbij zet je
altijd de optie <Referentiële integriteit afdwingen> aan, anders kun je de relatie net zo goed weglaten. Nu zijn de tabellen gekoppeld; in de tabel [tKlanten] zie je dus het veld [PlaatsnaamID]. Waar zet je nu die keuzelijst? Want je laat je gebruikers uiteraard niet getallen inkloppen. Is heel simpel: die keuzelijsten maak je op de gebruikersformulieren. En dáár maak je dan de constructie zoals je die nu dus in de tabel hebt staan.
Waarom geen keuzelijsten in tabellen? Eigenlijk heel simpel: in een tabel
wil je altijd de opgeslagen waarden kunnen zien. Zie een tabel als het fundament van een huis; zonder fundament valt het huis om, maar niemand zal het in zijn hoofd halen om de fundamenten te behangen! Is ook logisch, want als er scheurtjes in de fundering zitten, wil je ze wel kunnen zien. En dat kan niet als je ze behangen hebt! Datzelfde geldt dus ook voor tabellen: als er wat mankeert aan de data, moet je kunnen zien wat je feitelijk hebt opgeslagen! Sowieso is het mijn overtuiging dat een gebruiker
niets te zoeken heeft in een tabel. Die werkt bij mij
altijd via formulieren. En op die formulieren maak je dus alles netjes, met keuzelijsten, knoppen etc.
Eén van de (vele) problemen die je tegenkomt met keuzelijsten in tabellen is, dat je bij exports en sommige soorten queries hoe dan ook tóch de opgeslagen waarden ziet. Dus terwijl je in de
tabel de plaatsnaam 'Rotterdam' ziet, staat in je
export de waarde '1'. En wat dacht je van filteren in een query? Als je 'Utrecht' ziet in je query, en je wilt op 'Utrecht' filteren, dan wil je toch "Utrecht" intypen als criterium, en niet "12"?
Ik hoop dat je nu voldoende aansporing hebt om al je keuzelijsten alsnog om te zetten naar tekstvelden
.
