DB: NORM: Veel voorkomende kolommen in één tabel plaatsen?

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • Don Kedero
  • Registratie: Mei 2005
  • Laatst online: 28-05 20:41
Gewoon even een denkpiste. Ik heb enkele tabellen waarbij dezelfde kolommen (en types voorkomen) zoals bijvoorbeeld een Adres.

Tabellen:
  • Gebruiker
  • Klant
  • Afspraak
Deze 3 tabellen hebben de volgende kolommen gemeen: straat, huisnummer, postcode, gemeente
Een gebruiker heeft 1 adres, een klant kan meerdere adressen hebben, een afspraak kan ook meerdere adressen hebben.

Stel:
Ik heb 10 afspraken per dag (met elk 2 adressen), er zijn 365 dagen = 7300 records
Dit voor bijvoorbeeld 100 werknemers/gebruikers (even overdrijven) = 730000 records
En dit voor 10000 klanten = 740000
Niet vergeten de 100 werknemers/gebruikers = 740100 records (per jaar)

Dit zou geen probleem mogen zijn voor SQL-server (Express)

Infeite kan ik een 3 tabellen maken met samengestelde primairy key
  • GebruikerAdres (GebruikerID + AdresID)
  • KlantAdres (KlantID + AdresID)
  • AfspraakAdres (AfspraakID + AdresID)
Ik denk niet dat het zoveel kwaad kan om dit samen te gooien (misschien wat ingewikkelder, maar alles zit ook wel centraal in de tabel Adres) Ik zou het persoonlijk zo doen (zoals hierboven beschreven).
Maar misschien zijn er zaken die ik vergeet of over het hoofd zie, maar dit lijkt mij best oké.

[ Voor 0% gewijzigd door Don Kedero op 09-02-2011 11:40 . Reden: Tabelnaam correctie ]


Acties:
  • 0 Henk 'm!

  • SvMp
  • Registratie: September 2000
  • Niet online
Ik zou dat niet doen, met de reden dat je het adres niet los kunt zien van een klant of gebruiker. Je zult adressen nooit los bewerken van die klant of gebruiker. Anders wordt het als je meerdere klanten of gebruikers op één adres hebt staan, maar dan zijn er ook hele andere oplossingen denkbaar indien deze een logische groep vormen.

Wel kan ik me voorstellen dat het aantal adressen variabel is. Bijvoorbeeld werk of privé, of adressen van verschillende vestigingen. In dat geval maak je een tabel met adressen, een veld dat iets vertelt over het adres (werk, privé, vestiging, hoofdadres, etc..) en een foreign key die verwijst naar de klant of gebruiker

Acties:
  • 0 Henk 'm!

  • hellfighter87
  • Registratie: Mei 2008
  • Laatst online: 15:44
Ik zou een tabel address maken
en dan zoiets doen:
gebruiker + address id //gebruiker heeftmaar 1 adress? dus komt het addres id in degebruiker tabel.
klant -> heeftaddress(klantid, addressid) //klant kan meerdere addressen hebben en een adress aan meerdere klanten
afspraak -> heeftaddress(afspraakid, addressid) //hetzlefde als klant alleen dan andere naamgeving of in dezelfde tabel moet jezelf maar ff kijke :P

Wat zijn de voordelen hiervan:
- Je hebt nooit dubbele records van adressen.
- je kan heel makkelijk iemands address veranderen, simpelweg het addressid wijzigen in de (koppel)tabel

Nadele:
Je hebt wel minimaal 1 extra kople tabel nodig

[ Voor 28% gewijzigd door hellfighter87 op 09-02-2011 12:29 ]


Acties:
  • 0 Henk 'm!

  • tecsman
  • Registratie: Januari 2010
  • Laatst online: 02-06 19:50
Don Kedero schreef op woensdag 09 februari 2011 @ 11:39:
[knip]
Deze 3 tabellen hebben de volgende kolommen gemeen: straat, huisnummer, postcode, gemeente
Een gebruiker heeft 1 adres, een klant kan meerdere adressen hebben, een afspraak kan ook meerdere adressen hebben.
[knip]
Ik zou naast huisnummer ook een kolom toevoeging maken (in geval huisnummer = 1A, 1B of andere mogelijkheden)

Is in jouw geval gemeente hetzelfde als woonplaats (ik zou dat veranderen)
of zou 'woonplaats' er nog bij moeten?

  • Don Kedero
  • Registratie: Mei 2005
  • Laatst online: 28-05 20:41
tecsman schreef op woensdag 09 februari 2011 @ 21:17:
[...]
Ik zou naast huisnummer ook een kolom toevoeging maken (in geval huisnummer = 1A, 1B of andere mogelijkheden)

Is in jouw geval gemeente hetzelfde als woonplaats (ik zou dat veranderen)
of zou 'woonplaats' er nog bij moeten?
Gemeente is gewoon stad, dorp
Huisnummer zou een varchar(10) zijn dus die toevoeging kan erbij

Nu, bedankt voor jullie meningen! ik zal m'n denkpiste eens uitwerken, en eens zien hoe eenvoudig het is om deze te implementeren.

[ Voor 1% gewijzigd door Don Kedero op 10-02-2011 08:44 . Reden: typo's ]


  • Xesxen
  • Registratie: Juli 2009
  • Laatst online: 16:07
Is een varchar(10) niet erg veel voor een huisnummer? (Tenzij we in nederland huisnummers hebben van 1000000000...) Ik denk dat varchar(4) al voldoende is.

Rare vogel in spe


  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Nope.
Huisnummer zou een varchar(10) zijn dus die toevoeging kan erbij
Huisnummer kan een mediumint zijn, en de toevoeging moet je gewoon apart doen.

{signature}


  • EfBe
  • Registratie: Januari 2000
  • Niet online
Normaliseren heeft niets te maken met het reduceren van identieke columndefinities, maar met het reduceren van identieke data. Dat 2 of meer entities dezelfde subset columns hebben is niet erg. het gaat erom of de data in die columns identiek is of niet. Indien ja, dan moet je de columns uitnormaliseren, want dan zijn het aparte entities.

In de praktijk is een entity als 'adres' lastig. Het is nl. veelal zo dat een entity instance (de data) van het type adres niet meerdere keren gereferenced wordt, dus dat er uberhaupt duplicaten worden aangemaakt. Immers, als jij bv 2 klanten invult in een scherm, dan ga je niet het adres selecteren uit een al beschikbare lijst, maar vul je dat opnieuw in.

Het uitnormaliseren van adres is in theorie correct maar in de praktijk onnodig.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • Reptile209
  • Registratie: Juni 2001
  • Laatst online: 14:54

Reptile209

- gers -

SvMp schreef op woensdag 09 februari 2011 @ 12:18:
Ik zou dat niet doen, met de reden dat je het adres niet los kunt zien van een klant of gebruiker. Je zult adressen nooit los bewerken van die klant of gebruiker. Anders wordt het als je meerdere klanten of gebruikers op één adres hebt staan, maar dan zijn er ook hele andere oplossingen denkbaar indien deze een logische groep vormen.

Wel kan ik me voorstellen dat het aantal adressen variabel is. Bijvoorbeeld werk of privé, of adressen van verschillende vestigingen. In dat geval maak je een tabel met adressen, een veld dat iets vertelt over het adres (werk, privé, vestiging, hoofdadres, etc..) en een foreign key die verwijst naar de klant of gebruiker
En vergeet niet de adressen die helemaal los staan van je eigen bedrijf en van je klanten. Bijvoorbeeld overleg in een AC-restaurant langs de A12 of op Utrecht Centraal. Dat zijn adressen waar je met verschillende klanten terecht kunt, maar wat met geen van de partijen verbonden is.

Zo scherp als een voetbal!


  • Standeman
  • Registratie: November 2000
  • Laatst online: 16:47

Standeman

Prutser 1e klasse

Voutloos schreef op donderdag 10 februari 2011 @ 09:54:
[...]
Nope.
[...]
Huisnummer kan een mediumint zijn, en de toevoeging moet je gewoon apart doen.
Waarom zou je huisnummer / toevoeging apart benoemen? Het is niet zo dat ze los van elkaar gezien kunnen worden!

The ships hung in the sky in much the same way that bricks don’t.


  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Sla ze dan meteen in dezelfde kolom met postcode op, want aan enkel huisnummer en toevoeging heb je ook niets. :z

Overigens is huisnummer los wel nuttig, omdat postcode+huisnummer juist bepaald in welke straat iets ligt. En daarbij is toevoeging niet significant. En het ordent makkelijker, huisnummer is gewoon numeriek, het is efficienter, etc etc. Bovendien kan je ze niet triviaal samen opslaan en weer uit elkaar trekken, want sommige toevoegingen zijn numeriek.

{signature}


  • ajakkes
  • Registratie: Maart 2004
  • Laatst online: 16-05 22:32

ajakkes

👑

In principe is een postcode/huisnummer/toevoeging een uniek ID.

Je zou ervoor kunnen kiezen deze aan de verschillende tabellen toe te voegen en de overige gegevens centraal op te slaan.

Er wordt volgens mij al hard gewerkt aan tabellen waar je aan de hand van postcode huisnummer het dorp en straatnaam op kan zoeken.

Daarnaast kan je een werknemer zien als een klant, wat ze vaak ook zijn, met wat extra gegevens die je apart zou kunnen opslaan.

En bij een afspraak zou ik gewoon weer de postcode/huisnummer/toevoeging opslaan, omdat dit in veel gevallen toch uniek is.

Op een adres zitten meerdere klanten, een klant heeft meerdere adressen.
Een klant heeft meerdere afspraaklocaties, een afspraaklocatie meerdere klanten.
Een werknemer is een klant met meer gegevens, sla alle gegevens van de werknemer die in de klantentabel passen op in de klantentabel en verwijs in de werknemerstabel naar deze tabel.

👑


  • posttoast
  • Registratie: April 2000
  • Laatst online: 17:59
Voutloos schreef op donderdag 10 februari 2011 @ 13:46:
Sla ze dan meteen in dezelfde kolom met postcode op, want aan enkel huisnummer en toevoeging heb je ook niets. :z

Overigens is huisnummer los wel nuttig, omdat postcode+huisnummer juist bepaald in welke straat iets ligt. En daarbij is toevoeging niet significant. En het ordent makkelijker, huisnummer is gewoon numeriek, het is efficienter, etc etc. Bovendien kan je ze niet triviaal samen opslaan en weer uit elkaar trekken, want sommige toevoegingen zijn numeriek.
Heb je aan alleen een postcode niet al genoeg om te zien in welke straat een adres is? Volgens mij heb je daar het huisnummer niet voor nodig.

omniscale.nl


  • eamelink
  • Registratie: Juni 2001
  • Niet online

eamelink

Droptikkels

EfBe schreef op donderdag 10 februari 2011 @ 13:07:
In de praktijk is een entity als 'adres' lastig. Het is nl. veelal zo dat een entity instance (de data) van het type adres niet meerdere keren gereferenced wordt, dus dat er uberhaupt duplicaten worden aangemaakt.
Meestal niet nee, maar als ik zo de case van TS ziet lijkt het dat er afspraken gepland worden bij klanten. In dat geval zullen zowel afspraken als klanten naar hetzelfde adres refereren :)

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
posttoast schreef op donderdag 10 februari 2011 @ 13:57:
[...]

Heb je aan alleen een postcode niet al genoeg om te zien in welke straat een adres is? Volgens mij heb je daar het huisnummer niet voor nodig.
Veel mensen denken dat, maar er zijn behoorlijk veel postcodes waarbij je zonder huisnr de straat niet weet. Een willekeurig voorbeeld: http://www.postcode.nl/in...t&TreeID=1&address=2011vm

{signature}


  • Onbekend
  • Registratie: Juni 2005
  • Nu online

Onbekend

...

Maar de combinatie postcode-huisnummer blijft uniek.

Speel ook Balls Connect en Repeat


  • posttoast
  • Registratie: April 2000
  • Laatst online: 17:59
Voutloos schreef op donderdag 10 februari 2011 @ 14:07:
[...]
Veel mensen denken dat, maar er zijn behoorlijk veel postcodes waarbij je zonder huisnr de straat niet weet. Een willekeurig voorbeeld: http://www.postcode.nl/in...t&TreeID=1&address=2011vm
Weer iets geleerd, thanks :)

omniscale.nl


  • ajakkes
  • Registratie: Maart 2004
  • Laatst online: 16-05 22:32

ajakkes

👑

Onbekend schreef op donderdag 10 februari 2011 @ 14:11:
Maar de combinatie postcode-huisnummer blijft uniek.
Postcode/Huisnummer/Toevoeging is uniek.

Hoewel je niet heel veel zal afwijken van huis als je de toevoeging vergeet kan je brief nog wel eens op de verkeerde mat vallen.

En houdt rekening met huisnummers tot 5 getallen. Ik weet niet of er ergens in Nederland nog meer getallen worden gebruikt maar Graan voor Visch gaat tot 19900 ongeveer.

[ Voor 20% gewijzigd door ajakkes op 10-02-2011 14:43 ]

👑


  • Onbekend
  • Registratie: Juni 2005
  • Nu online

Onbekend

...

ajakkes schreef op donderdag 10 februari 2011 @ 14:37:
Postcode/Huisnummer/Toevoeging is uniek.
Je hebt gelijk. :P

Het roept wel meteen een paar vragen op als je dat apart gaat benoemen in de db.
Is een huisnummer altijd een nummer? Of bestaan er ook straten (buitenland?) waar de huizen letters hebben (of zelfs hele namen) i.p.v. nummers?
Is zo'n toevoeging altijd max. 1 karakter? Of zijn er praktijksituaties met 1Z, 1AA, 1AB enz.?

Speel ook Balls Connect en Repeat


  • Japius
  • Registratie: April 2003
  • Laatst online: 22-02 18:30
Bekijk even deze pdf.

Kijk vooral even naar pagina 10, over de verschillende toevoegingen.

  • ajakkes
  • Registratie: Maart 2004
  • Laatst online: 16-05 22:32

ajakkes

👑

Wikipedia: Huisnummer

Als je het huisnummer altijd al getal neemt. Zal je bij de toevoeging redelijk wat moeten toestaan. Zo blijkt er een huis te zijn met huisnummer 146A02, oftewel 146 verdieping a Kamer 2.
Dit zou je prima op kunnen slaan als huisnummer 146 toevoeging A02

Maar ook Rood of R zal in het vakje moeten passen. Of -401 als in 4e verdieping eerste appartement.


INT(4)-VARCHAR(2)-INT(5)-VARCHAR(5) zou genoeg moeten zijn. Of
INT(8)-INT(5)-(VARCHAR(5). Of als je het echt klein maar minder overzichtelijk wil opslaan INT(7)-INT(5)-VARCHAR(5).

👑


  • Remus
  • Registratie: Juli 2000
  • Laatst online: 15-08-2021
Een toevoeging is zeker niet altijd 1 karakter. Je hebt bijvoorbeeld toevoeging bis, I, II, III, a/b, combinaties van een huisnummer + een apartements nummer en noem maar op. Toevoegingen zijn iig niet echt gestandardiseerd en kunnen in principe uit redelijk veel karakters bestaan.

Zie ook: http://www.waarderingskam.../viewcontent.aspx?id=1095

  • Croga
  • Registratie: Oktober 2001
  • Laatst online: 13:58

Croga

The Unreasonable Man

Als we dan toch aan het normaliseren zijn.....

Gebruiker en Klant zijn beide personen. Waarom maak je daar niet simpelweg één tabel van?

Adres is absoluut een aparte tabel aangezien het niet specifiek verbonden hoeft te zijn met de persoon. Zeker als je meerdere gebruikers of klanten van hetzelfde bedrijf hebt. En zeker als je een bedrijf met meerdere locaties hebt. In dat geval wordt persoon:adres een N:N relatie. Één persoon kan meerdere adressen hebben en één adres kan bij meerdere personen horen.

Afspraken bestaan vervolgens uit:
- Meerdere personen
- Één adres
- Één tijdsperiode
Een verrijkte koppeltabel dus.

  • fleppuhstein
  • Registratie: Januari 2002
  • Laatst online: 27-05 13:58
Een adres blijft altijd een moeilijk object om te normaliseren, voor hier is het standaard om een huisnummer en een postcode te hebben. Sterker nog, het is wat een adres in Nederland uniek maakt. Voor andere landen gelden alleen andere regels, zo heeft Ierland bijvoorbeeld geen postcode, en kent Engeland niet perse huisnummers, maar gebruiken ze vaak huisnamen. Ook zijn er landen waarbij een blok nummer wordt vermeld in het adres.

Verder is het opnemen van een koppel table tbv het adres goed, zolang je het 1 op N en niet N op N doet, Klant X en Y kunnen wel op het zelfde adres zitten, maar... als bedrijf X verhusit, gaat Y niet automatisch mee. Of andere situaties als een werknemer van X ineens bij bedrijf Y gaat werken.

Acties:
  • 0 Henk 'm!

  • Crazy D
  • Registratie: Augustus 2000
  • Laatst online: 06:44

Crazy D

I think we should take a look.

Hou je er wel even rekening mee dat als je adressen in een losse tabel stopt, je het de gebruiker duidelijk moet maken dat bij een adreswijziging niet het adres zelf aangepast moet worden, maar de koppeling? Altijd leuk bij verzamelgebouwen, verhuis je in 1 klap 100 bedrijven in plaats van 1 :+

Er zijn best wat redenen te bedenken waarom 1 adres meerdere keren mag voorkomen, en dat is volgens mij vooral afhankelijk van de context. Als je samenwoont heb je beiden hetzelfde adres. Het behoort niet bij dezelfde entiteit. Je wilt het wel normalizeren als aan 1 entiteit het adres 2 keer is gekoppeld.

Voor die loze adressen zoals een wegrestaurant zou je ook een apart adrestypes kunnen maken of eventueel een relatie van een bepaald type, dat je kunt koppelen. Dan kun je die aan een afspraak koppelen als zijnde Afspaaklocatie (of als de locatie gewoon bij de klant is, de locatie van de klant...). Zonder dat je voor iedere afspraak ook echt al die adressen moet opslaan.

Aan de andere kant, hoe belangrijk is de historie? Vandaag Dorpsstraat 1, morgen na adreswijziging is de afspraak opeens ook op een andere locatie? Voor afspraken in de toekomst aannemelijk, uit het verleden onlogisch.

Exact expert nodig?


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
eamelink schreef op donderdag 10 februari 2011 @ 13:58:
[...]
Meestal niet nee, maar als ik zo de case van TS ziet lijkt het dat er afspraken gepland worden bij klanten. In dat geval zullen zowel afspraken als klanten naar hetzelfde adres refereren :)
Dat impliceert dat je ze invult aan de hand van 'zoek adres op'. Dit kan het beste met een postcode database (die je gewoon kunt kopen), iedere andere methode levert op dat je toch dingen met de hand moet invullen, wat dus duplicate addresses oplevert.

CrazyD hierboven heeft ook een aantal goede punten.

(maar we zijn nu wel ver van het topic verwijdered ;)).

[ Voor 9% gewijzigd door EfBe op 11-02-2011 09:21 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • Don Kedero
  • Registratie: Mei 2005
  • Laatst online: 28-05 20:41
Ik ben verschoten van het aantal reacties hierop (blijkbaar nog een harde noot om te kraken). De denkpiste was infeite als volgt:
  • Een klant kan 1 of meerdere adressen hebben
  • Een afspraak heeft 1 klant
  • Een afspraak kan meerdere adressen hebben. Bij het toevoegen van een adres krijgt de gebruiker de keuze om het adres uit een lijst te kiezen van mogelijke klant adressen (een afspraak hangt aan een klant, dus we kunnen de adressenlijst ophalen) OF de gebruiker kan een adres manueel toevoegen die niet noodzakelijk rechtstreeks aan de klant hangt, maar die wel éénmalig om reden x aan de afspraak hangt (éénmalige afwijking van een locatie).
  • Als een gebruiker een klant adres zou wijzigen kan de applicatie een popup tonen met de melding dat dit adres gekoppeld is aan één of meerdere afspraken. En de gebruiker vragen of deze zeker mag gewijzigd worden (+ melding van de gevolgen ... zoals wat met afspraak adressen van het verleden?) of de gebruiker voorstellen een nieuw adres toe te voegen (en het oude op inactief te plaatsen)
Het gaat trouwens om een Belgisch adres (straat + nummer + bus + postcode + gemeente). Ik had niet meteen rekening gehouden met het feit dat andere landen soms totaal andere adres samenstellingen/logica kunnen hebben.

  • henrim123
  • Registratie: Juni 2009
  • Laatst online: 19-02-2013
ik denk dat je een klant een of meerdere klantennummer(s) moet geven.
tabel1 PK klant = FK klantnummer

dan een tabel waar je de adres gegevens + de klant gegevens inzet
tabel2 PK klantnummer ...... data fields

in tabel1 kan je de historie opbouwen door andere "oude klantnummers" opteslaan

Het voordeel is ook dat je op deze manier kan opslaan in tabel2 wie en wanneer de klant gegevens heeft gewijzigd, ook spelfouten in de naam van de klant en of ander gegevens die niet met het adres te maken heeft kan je zo opslaan , contract nummer of dat de klant op ROOD staat of ZWART.

vervolgens maak je een tabel3 voor de afspraken.
Hier in kopieer je gegevens die in table2 staan in de afspraak tabel3, of kan je Manuel invullen met een afwijkend adres, het lijkt onzinnig maar dit is om correcties en manipulaties van het adres gegevens (table2) tegen te gaan die kunnen gedaan worden.

Dus de afspraak tabel is een soort carbon kopie van de afspraak tussen het bedrijf en de klant.. zorg dat die Nooit beïnvloedbaar word door tabel wijzigingen ..
je zou dan de afspraken ouder als 1 of 3 jaar kunnen archiveren en dan uit de actieve tabel3 verwijderen en naar een archief tabel4 kunnen schrijven zodat je tabel3 snel blijft.

Als je een adres wijziging doet hoef je alleen te kijken naar de openstaande afspraken met het zelfde klantnummer. Je zal dan een lijst kunnen afdrukken zodat de klant(en) gebeld kunnen worden om te vragen of de afspraak gewijzigd moet worden i.v.m. het veranderde adres, maar als het adres Manuel reeds ingevuld is dan is dat niet nodig .
Als je de afspraak moet wijzigen dan kopie je de oude afspraak en close je die met note "wijziging" en dan wijzig je de gekopieerde afspraak zo dat hij correct is en sla je die op als een nieuwe afspraak (new afspraaknummer)

Een goed structuur opbouwen foor klant gegeven is niet zo eenvoudig als je denk ..
vergeet niet wie en wanneer iets verandert is in de tabellen te bouwen ...

Dit is een vereenvoudigde methode die ik gebruikte voor een ERP applicatie .
De database structuur word nog veel moeilijker met partners, filialen en ander mogelijke "klanten" of "locaties". Ook moet je rekening houden met samenvoegen van filialen i.v.m. verhuizingen enz...
Pagina: 1