[Access] advies over database schema

[Verwijderd]

Hoi,

Ik ben zojuist begonnen met het ontwerp van een programma voor een vereniging. De eerste stap is uiteraard een goed database ontwerp. Hierin ben ik eerlijk gezegd maar een kneus.

Stand van zaken:

Na wat normalisaties kwam ik hierop uit. Het lijkt met net iets te omslachtig, zeker voor adresgegevens.
In het achterhoofd moet je volgende eisen houden:
- Per adres kunnen er meerder mensen zijn (vb: een gezin)
- Een gezin moet makkelijke te verhuizen zijn naar een ander adres

Wat vinden jullie van dit brouwel?
Hoe krijg ik dit optimaal?

[Eskimootje]

Straat kan gewoon in tblAdres en Gemeente ook wel. Zo vaak zullen die niet van naam veranderen.

[pjonk]

Zoals mijn voorganger al opmerkte kun je de tblStraat en tblGemeente beter gewoon opnemen in tblAdres. Qua naamgeving zou ik de primaire sleutel van een tabel ID noemen ipv Nummer, want dit is nogal verwarrend zeker in jouw situatie als je over verschillende soorten nummers praat.

[Verwijderd]

Dank voor jullie suggesties, ik neem ze mee in mijn ontwerp!

[NMe]

Kunnen alleen personen een adres hebben in je database straks, of komen er ook andere dingen als leveranciers in? Als alleen personen een adres hebben, dan kun je dat beter ook gewoon in één tabel zetten, waardoor je maar één tabel overhoudt in het geval val het plaatje hierboven. Eén op één relaties hebben niet echt geweldig veel nut in zo'n geval.

[Eskimootje]

-NMe- er kunnen meer personen op 1 adres wonen vandaar dat hij deze losgekoppeld heeft

[NMe]

Hmm, ja, inderdaad, ik lees het ook net. Dan is het inderdaad wel verstandig om het op een dergelijke manier te doen.

[Verwijderd]

Spliting gaat redundatie tegen alleen zul je daarbij meer joins moeten maken.
Soms is de-nomalisatie om technische redenen gewenst.
Maar daar zijn de meningen vast over verdeelt.

[Boss]

In een ander topic heeft er ook al een discussie over gelopen, maar:
Waarom Straat en nummer in twee velden? Ga je daar voordeel van hebben? Ook in de database die jij nu aan het maken bent? Als je straat en nummer splitst, moet je ook een 3e veld makne: toevoeging (voor boven, tegenover, rood, b enzo).

En dan nog is de voornaamste optie om straat, nummer en toevoeging te splitsen alleen maar dat je dan een postcodetabel kan gebruiken voor het opzoeken van postcodes.

Anders geeft het alleen maar irritatie bij het invullen (type maar eens een adres, de 'natuurlijke' manier is om het nummer er meteen achteraan te zetten en die tab vergeet je!)

[djluc]

Boss schreef op zondag 30 januari 2005 @ 10:14:[...]
Anders geeft het alleen maar irritatie bij het invullen (type maar eens een adres, de 'natuurlijke' manier is om het nummer er meteen achteraan te zetten en die tab vergeet je!)

Dit is het database model. Dit staat nog los van de interface. Je kan ook een enkel sring-input veld maken wat je middels een slim scriptje uit laat zoeken hoe en wat er gesplitsts moet worden.

[Reptile209]

Nog een praktische: ik denk dat je het veld "Sorteernaam" kunt laten vallen, als je een veld met "Tussenvoegsel" opneemt:
Voornaam: Klaas
Tussenvoegsel: van der
(Achter)Naam: Vries
Tenzij je met sorteernaam een ander idee in je hoofd had he .

En als er meerdere mensen op één adres wonen, moet je die dan op een of andere manier als "gezin" kunnen koppelen? Dus nog een link naar een andere naam-ID als "gezinshoofd"?

[_Thanatos_]

tblGemeente zou ik niet gebruiken, maar het gewoon in 1 tabel plempen. Stel dat er buitenlandse personen in komen (niet zeggen "dat gebeurt niet", want dan gebeurt het toch ). In het buiten zou de postcode weleens anders kunnen werken dan per gemeente.