Hoe verschillende adresregels te koppelen Postgresql

[jbdeiman]

Voor een applicatie zit ik qua database ontwerp met het volgende probleem:

We hebben 2 entiteiten: Instellingen (feitelijk bedrijfsgegevens) en Persoonsgegevens, waarbij deze persoonsgegevens vervolgens nog te onderscheiden zijn in: Cliënten, Relaties van deze cliënten en Personeelsleden.
Van deze entiteiten moeten adresgegevens opgeslagen kunnen worden, waarbij het mogelijk is / moet zijn om meerdere adressen voor elk van deze entiteiten op te slaan
- bij een bedrijf bijvoorbeeld: Bezoekadres, Contactadres kan anders zijn
- bij een persoon heb je bijvoorbeeld: Woon adres, Factuur adres, Correspondentie-adres

Het liefst hebben we adressen, omdat die allemaal van dezelfde entiteit zijn in eenzelfde tabel, maar ivm 1 op meer relaties is dat niet handig, vooral omdat je ook met 2 entiteiten zit waaraan een adres gekoppeld kan zijn.

Hiervoor is op dit moment (in de huidige opzet, welke we willen verbeteren) de volgende optie gebruikt:
- Een bedrijf of persoon hebben een koppeling met een "groepeernummer_adres" tabel. Het id hiervan is bepalend voor een groep adressen gekoppeld aan deze entiteit.

Kort in een structuurtje (meer ter uitgewerkt:
PERSON
groepeernummer_adres
personalia

COMPANY
groepeernummer_adres
bedrijfsgegevens

ADDRESS
groepeernummer_adres
adresgegevens


Hebben jullie misschien een idee hoe dit handig op te zetten kan zijn? Voor de duidelijkheid: er wordt gebruik gemaakt van PostgreSQL, wellicht dat dit meer specifieke oplossingen biedt voor dit probleem.

[Boss]

Ik zou over adressen niet te moeilijk doen qua normaliseren. Als er twee bedrijven op hetzelfde adres zitten: gewoon 2x toevoegen in de adrestabel. De 'quick and dirty' oplossing die wij nog wel eens gebruiken:
PERSON
personid

COMPANY
companyid

ADDRESS
addressid
companyid
personid
adresgegevens

Bij ADDRESS is dan het companyid of het personid ingevuld. Voor een derde intiteit die ook adressen krijgt nog een kolom toevoegen. Zo heb je alle adressen in 1 tabel en kan je prima alle benodigde joins maken.

[jbdeiman]

Ik zat zelf te denken aan een optie van Postgres, maar wou dat niet gelijk als suggestie opgeven:

De basis is het adres, het adres is ergens aan gekoppeld dit kan een cliënt of bedrijf zijn. Je kan dan met inharitance bijvoorbeeld deze adressen extenden, maar ook dat lijkt me niet een erg handige oplossing. Ik kwam niet verder dan het idee wat je aandraagt, maar er blijft ergens wat knagen, een gevoel dat het toch beter moet kunnen.

Ter info over heritance
http://www.postgresql.org...tutorial-inheritance.html

[Janoz]

Wat is het probleem van koppel tabellen met een functie?

Voor de koppeling tussen persoon en adres:
persoonid
adresid
adresfunctie

Voor koppeling bedrijf en adres
bedrijfid
adresid
adresfunctie


En als de adresfuncties heel vast staan en er van elk type maar 1 is, dan kun je ook overwegen om gewoon meerdere id's in de persoons- en bedrijfstabel opnemen.

correspondentieadresid, woonadresid, factuuradresid,


Zolang je geen koppeling met de BAG hebt zou ik me trouwens niet druk gaan maken over dubbele adressen in de adressentabel. Als je af en toe gewoon controleert of een adres überhaupt nog gekoppeld is om eventueel te kijken of er wat geschoond moet worden heb je verder eigenlijk nergens last van.

[jbdeiman]

Janoz,

Dat klinkt wel als een goede optie, ook voor de lange termijn kan dit prima voldoen, aangezien we eigenlijk nooit meer dan deze 2 typen adressen hebben, om het maar zo te noemen. Het voordeel is dat we voor een zorginstelling (tevens een bedrijf, van een bepaald type met wat extra informatie) de "company" tabel kunnen uitbreiden, met de eerder genoemde inheritance.
Zo kunnen we alles toch op een eenvoudige manier ondervangen, bedankt voor je inbreng.

[jbdeiman]

Ik weet dat ik als laatste heb gepost, maar ik heb een vervolgvraag:
Als we nu nog een soort adressen (of een andere soort entiteit waaraan een adres gekoppeld kan worden) krijgen, of nog een paar entiteiten, dan moeten we natuurlijk allerlei koppeltabellen aanmaken. Of zijn daar nog betere oplossingen voor?