[sql] Meerdere koppeltabellen of iets anders?

[StephanVierkant]

Met het opzetten van enkele databases loop ik steeds tegen hetzelfde probleem aan. Voor het gemak neem ik even het voorbeeld van een CRM-systeem. In dit systeem kun je een aantal zaken bijhouden:

• Klanten/prospects
• Leveranciers
• Personeel

Ik heb al die gegevens nu in één Excelbestand (met drie tabbladen), maar echt lekker werkt dat niet. Ik wil ze nu overzetten naar een MySQL-database.

Nu loop ik tegen het probleem aan hoe ik al deze informatie het beste in een database kan stoppen. Alle klanten, leveranciers en personeelsleden hebben natuurlijk meerdere emailadressen, meerdere telefoonnummers (mobiel, fax, thuis, werk, etc.) en meerdere adressen (bezoekadres, postadres), ga zo maar door.

Nu had ik het volgende als eerste bedacht:

• klanten (id, naam)
• klanten_adres (id, klant_id, straat, huisnummer, postcode, plaats)
• leveranciers (id, naam)
• leveranciers_adres (id, leverancier_id, straat, huisnummer, postcode, plaats)
• etc

Nu vraag ik me af of dit niet beter kan. Nu zit ik aan het volgende te denken:

• klanten (id, naam)
• leveranciers (id, naam)
• personeel (id, naam)
• adres (id, straat, huisnummer, postcode, plaats)
• koppel_klanten_adres (klant, adres)
• koppel_leveranciers_adres (leverancier, adres)
• koppel_personeel_adres (personeel, adres)

Het komt bij mij regelmatig voor dat een personeelslid ook klant en/of leverancier is of dat meerdere bedrijven op hetzelfde adres gevestigd zijn, bijvoorbeeld omdat ze aan elkaar gelieerd zijn. Ik gebruik nu adres als voorbeeld, maar dit kan bijvoorbeeld ook een notitie zijn: 'Vandaag een televisie verkocht' kan betrekking hebben op werknemer A, die een televisie van leverancier B net aan klant C heeft verkocht. Je kunt dan natuurlijk notitie (id, werknemer_id, leverancier_id, klant_id) aanmaken, maar als je net een Sony én een Philips hebt verkocht, zit je weer met een probleem.

Ik kan me niet anders voorstellen dat dit een dilemma is dat vaker ter sprake is gekomen. Kan iemand me nuttige tips geven hoe ik dit varkentje kan wassen?

[ Voor 4% gewijzigd door StephanVierkant op 06-06-2011 19:13 ]

[Verwijderd]

Is het aantal soorten adres per klant/leverancier beperkt, dan kan je dat best op hetzelfde record houden.

Wij werken ook met zowel klant- als leveranciersgegevens. Bij klanten kennen we het 'adres' en een 'afwijkend afleveradres' en een drietal kolommen voor telefoon, gsm en fax. Bij leveranciers kennen we een goederen- en een factuuradres.

[StephanVierkant]

Van een adres wil ik weten:

• Straat
• Huisnr
• Toevoeging
• Postcode
• Plaats
• Provincie
• Land
• Latitude
• Longitude
• Opmerkingen

Het zou betekenen dat ik 20 velden moet toevoegen bij een aflever- en een factuuradres. Geen optie lijkt me. Daarbij komt dat het probleem zich niet alleen tot adressen beperkt.

[kwaakvaak_v2]

Adres is een tabel, en dan een koppeltabel waarin je vastlegt wat het type is wat je koppelt, en een id van het object waar je het aan koppelt. Ik zou mij vooral geen zorgen maken over de hoeveelheid velden en tabellen, want je hoeft niet alles in het scherm te tonen en een beetje SQL omgeving gaat niet echt zweten van een paar tabellen extra. Zolang je maar rekening houd met indexen etc.

[ Voor 3% gewijzigd door kwaakvaak_v2 op 06-06-2011 18:24 ]

[Boss]

Veel voorkomend probleem, kom ik ook vaak tegen bij ons. Wat wij dan nog wel eens doen is (om in jouw voorbeeld te blijven): maak in de Adres tabel meerdere foreign keys: BedrijfID, PersoonID, ...ID waarvan je er dan per record steeds maar 1 gebruikt. Dan kan je het aantal tabellen beperkt houden, hoewel dat natuurlijk geen eis op zich is. Qua normalisatie kan je verder gaan, maar ergens moet je zo af en toe ook gewoon praktisch zijn.

[The Eagle]

Ik zou sowieso bij ieder adres een veld toevoegen die aangeeft wat voor type adres het is (business, prive, alternatief prive, alternatief buisiness, etc)

Verder snap ik niet waarom je die lat / longitude wilt weten. Hoe had je gedacht die voor iedereen te gaan vullen bij de invoer van een nieuw adres?

Andere opmerkingen:
- Zorg er voor dat je een adres actief en inactief kunt zetten per type, het liefste per datum. Dan kun je zelf bepalen hoeveel adressen er van en bepaald type mogelijk zijn.

- Zorg ervoor dat je huisnummer toevoeging minimaal 6 karakters lang is. Ik ben ze ooit tegengekomen als "5 hoog" en dat was een officieel adres. Meer dan 6 overigens nog nooit.

[StephanVierkant]

The Eagle schreef op maandag 06 juni 2011 @ 22:02:
Ik zou sowieso bij ieder adres een veld toevoegen die aangeeft wat voor type adres het is (business, prive, alternatief prive, alternatief buisiness, etc)

Verder snap ik niet waarom je die lat / longitude wilt weten. Hoe had je gedacht die voor iedereen te gaan vullen bij de invoer van een nieuw adres?

Andere opmerkingen:
- Zorg er voor dat je een adres actief en inactief kunt zetten per type, het liefste per datum. Dan kun je zelf bepalen hoeveel adressen er van en bepaald type mogelijk zijn.

- Zorg ervoor dat je huisnummer toevoeging minimaal 6 karakters lang is. Ik ben ze ooit tegengekomen als "5 hoog" en dat was een officieel adres. Meer dan 6 overigens nog nooit.

Coördinaten hoef je niet zelf in te vullen, maar kun je ook opvragen met Google Maps o.i.d. ;-)

En '5 hoog' is overigens geen huisnummer maar een toevoeging.

Boss schreef op maandag 06 juni 2011 @ 21:31:
Veel voorkomend probleem, kom ik ook vaak tegen bij ons. Wat wij dan nog wel eens doen is (om in jouw voorbeeld te blijven): maak in de Adres tabel meerdere foreign keys: BedrijfID, PersoonID, ...ID waarvan je er dan per record steeds maar 1 gebruikt. Dan kan je het aantal tabellen beperkt houden, hoewel dat natuurlijk geen eis op zich is. Qua normalisatie kan je verder gaan, maar ergens moet je zo af en toe ook gewoon praktisch zijn.

Dank! Dat lijkt me inderdaad de beste oplossing.

[The Eagle]

Stephan4kant schreef op maandag 06 juni 2011 @ 23:03:
[...]

Coördinaten hoef je niet zelf in te vullen, maar kun je ook opvragen met Google Maps o.i.d. ;-)

En '5 hoog' is overigens geen huisnummer maar een toevoeging.
[...]

Dank! Dat lijkt me inderdaad de beste oplossing.

Dan nog, waarom zou je die coordinaten in een CRM systeem willen hebben als je ze, mocht je ze nodig hebben, via een tooltje of een XMLlink zo op kunt vragen
En 5hoog is idd een toevoeging, maar dat zei ik ook

[chime]

Waarom niet werken met contactpersonen, die dan ofwel klant/leverancier kunnen zijn.

[Razr]

Je zou ook nog kunnen kijken naar het gebruik van GUIDs. Dan hoef je geen kolommen te maken voor de verschillende entiteiten (immers is de sleutel altijd uniek).

Maar niet vergeten even onderzoek te doen over de voor en nadelen

[sonix666]

Ik zou, voor zover ik kan beoordelen in jouw beschrijving, gaan voor de adrestabel per type, dus de eerste optie. Wat je jezelf zou moeten afvragen is namelijk wat de levensduur van een adres is. Kan een adres op zichzelf bestaan zonder dat er een klant of leverancier gebruik van maakt. Als je gebruik maakt van een cascading foreign key, dan verdwijnt het adres ook als een leverancier of klant verdwijnt.

In de tweede optie moet je zelf handmatig bijhouden of het adres nog in gebruik is en zo niet, het dan handmatig verwijderen.

[StephanVierkant]

Razr schreef op donderdag 09 juni 2011 @ 22:34:
Je zou ook nog kunnen kijken naar het gebruik van GUIDs. Dan hoef je geen kolommen te maken voor de verschillende entiteiten (immers is de sleutel altijd uniek).

Maar niet vergeten even onderzoek te doen over de voor en nadelen

Ik zie nog niet helemaal wat het voordeel daar van is. Als je de tabel klanten hebt met 3 klanten (id's 1,2,3) en een tabel leveranciers met 3 leveranciers (id's 4,5,6) is het toch hetzelfde? Als je dan vanuit de adressenlijst refereert aan id 4, dan weet je dat het bij een leverancier hoort. Maar kun je dat ook gemakkelijk uitvinden in SQL in plaats van logisch verstand?

[Voutloos]

Die GUID hint begrijp ik ook niet, en lijkt ook gewoon niet op dit topic te slaan. Of het is een idee voor een generieke db in een db implementatie, maar dat is in dit geval (en 99 vd 100 andere gevallen) geen goed plan.

Alle adressen hebben dezelfde eigenschappen, dus je hebt maar 1 adres entiteit nodig. Het verschil zit hem in de andere kant van de relatie. Dan kom je vanzelf op de verschillende koppeltabellen uit.