Toon posts:

[sql] Meerdere koppeltabellen of iets anders?

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0Henk 'm!

  • StephanVierkant
  • Registratie: Mei 2003
  • Laatst online: 05-06 08:56
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]


Acties:
  • 0Henk 'm!

Anoniem: 251679

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.

Acties:
  • 0Henk 'm!

  • StephanVierkant
  • Registratie: Mei 2003
  • Laatst online: 05-06 08:56
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.

Acties:
  • 0Henk 'm!

  • kwaakvaak_v2
  • Registratie: Juni 2009
  • Laatst online: 06-06 21:46
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]

Driving a cadillac in a fool's parade.


Acties:
  • 0Henk 'm!

  • Boss
  • Registratie: September 1999
  • Laatst online: 09:35

Boss

+1 Overgewaardeerd

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 process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.


Acties:
  • 0Henk 'm!

  • The Eagle
  • Registratie: Januari 2002
  • Laatst online: 22:02

The Eagle

I wear my sunglasses at night

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.

Al is het nieuws nog zo slecht, het wordt leuker als je het op zijn Brabants zegt :)


Acties:
  • 0Henk 'm!

  • StephanVierkant
  • Registratie: Mei 2003
  • Laatst online: 05-06 08:56
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.

Acties:
  • 0Henk 'm!

  • The Eagle
  • Registratie: Januari 2002
  • Laatst online: 22:02

The Eagle

I wear my sunglasses at night

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 B)

Al is het nieuws nog zo slecht, het wordt leuker als je het op zijn Brabants zegt :)


Acties:
  • 0Henk 'm!

  • chime
  • Registratie: Januari 2005
  • Laatst online: 08-06 00:00
Waarom niet werken met contactpersonen, die dan ofwel klant/leverancier kunnen zijn.

  • Razr
  • Registratie: September 2005
  • Niet online
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
  • Registratie: Maart 2000
  • Laatst online: 08-06 11:58
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
  • Registratie: Mei 2003
  • Laatst online: 05-06 08:56
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
  • Registratie: Januari 2002
  • Niet online
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.

{signature}

Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee