adres opslaan
Ik zit me iets af te vragen. Als ik "vroeger" een adres moest opslaan in de database, dan deed ik dat bij de gebruiker zelf:
Code (php)
1
2
2
1 piet pietersen grotestraat 1 9999aa amsterdam
2 jan jansen stationstraat 10 1111bb zwolle
2 jan jansen stationstraat 10 1111bb zwolle
* De namen en adressen zijn fictief.
Nu vraag ik me af. Als je geen gebruik maakt van een externe adressen-service, hoe sla je dan eigenlijk adressen op?
Maak je een losse tabel voor de adressen? En sla je dan per rij een compleet adres op? Of ga je ook een tabel met straat/plaatsnamen maken en maak je daar referenties naar? Wat is een gebruikelijke manier?
id voornaam achternaam adres
1 Piet Pietersen 1
2 Klaas Pietersen 1
3 Lucia Pietersen 1
4 Jan Jansen 2
id straatnaam huisnummer postcode woonplaats
1 Grotestraat 1 9999a Amsterdam
2 Stationstraat 10 1111b Zwolle
{
"Piet":{
naam:"Piet Pietersen",
straat:"GroteStraat",
huisnummer:"1",
postcode:"9999aa",
stad:"amsterdam"
},
"Jan":{
naam:"Jan Jansen",
straat:"StationStraat",
huisnummer:"10",
postcode:"1111bb",
stad:"zwolle"
}}
En als je dat op een pagina wilt weergeven gebruik je dit script:
Code (php)
Ik hoop dat dit je helpt! Een tip: die json zou ik opslaan met .json als exentie
Met Vriendelijke Groet:
Pascal Gerrist
@Ries
Ik snap jouw voorbeeld, maar hoe vergelijk je dan de adressen? Vergelijk je ze op postcode en huisnummer? Of ook op straatnaam? En wat doe je bijv. als persoon A en B op hetzelfde adres wonen, maar persoon A schrijft Dr. Kuiperstraat en persoon B schrijft Doctor Kuiperstraat?
Nog een tip: sluit een goede aansprakelijkheidsverzekering af, liefst eentje die bij "grove nalatigheid" toch niet zo moeilijk doet.
Met daarbij dus een tabel met postcodes, straatnamen en plaatsnamen
Hoe veel adressen kan iemand hebben?
Heb je altijd de straatnaam EN het huisnummer EN de postcode EN de plaatsnaam nodig?
Of wil je soms ook dingen per plaats weten? (Plaatsnaam in zijn eigen tabel stoppen kan dan correct zijn.)
Dit is alleen op een case-by-case basis correct te antwoorden. Ook de definitie van 'correct' hangt van de situatie af.
Misschien heb je ooit van Big Data gehoord. Een net genormaliseerde database is over het algemeen niet geschikt om snel het resultaat op een complexe vraag te beantwoorden.
Wat kan je dan doen? Telkens wanneer je nieuwe data uit je genormaliseerde database importeert de-normaliseer je het naar een structuur die meer geschikt is (star-schema bijvoorbeeld) om die specifieke vraag te beantwoorden.
"En wat doe je bijv. als persoon A en B op hetzelfde adres wonen, maar persoon A schrijft Dr. Kuiperstraat en persoon B schrijft Doctor Kuiperstraat?"
Dan laat je ze alleen huisnummer en postcode invullen. Vervolgens koop je een postcode database (bijvoorbeeld http://shop.postcode.nl/, of in het geval van webshops hebben ze een gratis API: https://api.postcode.nl/) en heb je gebruikers minimale en normaliseerbare data in laten voeren die je kunt gebruiker om uitgebreidere data te achterhalen.
Een belangrijk deel van programmeren is je requirements analyseren, verschillende aanpakken te bedenken, en vervolgens op basis van voor- en nadelen de meest optimale keuze te maken.
http://nl.wikipedia.org/wiki/Databasenormalisatie
Je kunt het zo gek maken als je zelf wilt. Maar voor je het weet heb je zelf een adressen service met een paar miljoen items gemaakt ;-).
Ik denk dat de controle en verwerking van de invoer van de gebruikers ook de sleutel is om het geheel werkbaar te maken en te houden.
Hier een link naar wat informatie over het normaliseren van data voor databases; Je kunt het zo gek maken als je zelf wilt. Maar voor je het weet heb je zelf een adressen service met een paar miljoen items gemaakt ;-).
Ik denk dat de controle en verwerking van de invoer van de gebruikers ook de sleutel is om het geheel werkbaar te maken en te houden.
>> Met daarbij dus een tabel met postcodes, straatnamen en plaatsnamen
Oké... maar dan ga je dus wel uit van een bestaande tabel met plaats/-straatnamen, in plaats van zelf laten invullen??
@Dos:
>> of in het geval van webshops hebben ze een gratis API: https://api.postcode.nl/) en heb je gebruikers minimale en normaliseerbare data in laten voeren die je kunt gebruiker om uitgebreidere data te achterhalen.
Ah oké. Daar zou ik me dan in moeten verdiepen. Zijn daar echt geen kosten aan verbonden? En sla je dan per user (in de usertabel) de postcode en het huisnummer op? En die geef je telkens door aan de api?
Laat ik m'n vraag nog wat uitbreiden. Stel je hebt een webshop. Is het dan überhaupt gebruikelijk om mensen zelf hun adres in te laten vullen? Of werk je altijd met een externe database en match je dan op de postcode en huisnummer van de gebruiker?
Mja... nu ik erover nadenk weet ik het antwoord eigenlijk al... hangt natuurlijk af van de situatie...
Met die api van postcode.nl wordt het nog spannend wanneer iemand met een adres in het buitenland in je webshop iets wil bestellen... Zelf heb ik eens een webshop gemaakt waarvan ik wist dat er geen duizenden gebruikers zouden zijn, maar wel internationaal. Daar heb ik alle naw gegevens gewoon in 1 tabel gezet.
Klanten willen vaak iets op andere adressen laten bezorgen: op het werk, bij familie, in het tweede huis...
Daarnaast verhuizen mensen nu eenmaal wel eens, maar wil je in je historische data kunnen terugvinden wanneer je wat waar geleverd hebt en aan welk adres de bijbehorende factuur geadresseerd was. Het een hangt samen met de wettelijke leveringsverplichting, het ander met de fiscale bewaarplicht.
>> Daar heb ik alle naw gegevens gewoon in 1 tabel gezet.
In de usertabel, of in een aparte tabel? Kun je eens een rij van zo'n tabel laten zien (mag met fictieve gegevens)?
@Ward:
>> Daarnaast verhuizen mensen nu eenmaal wel eens, maar wil je in je historische data kunnen terugvinden wanneer je wat waar geleverd hebt en aan welk adres de bijbehorende factuur geadresseerd was. Het een hangt samen met de wettelijke leveringsverplichting, het ander met de fiscale bewaarplicht.
Goed punt. Maar hoe sla jij die adressen dan op? In een losse tabel, maar sla je het complete adres op, of werk je met een externe database/api?
Voor adressen zou ik dan inderdaad een aparte tabel gebruiken.
Kun jij eens laten zien hoe jij dat opslaat, hoe een rij in de tabel er uitziet (met fictieve gegevens)?
Ik gebruik een datastructuur die is toegespitst op pakketpost via PostNL. Als je wilt weten hoe die in elkaar zit, kan ik je wel even een PB sturen.
Jij hebt mij weleens de (niet cynisch bedoelde) vraag gesteld: waar houdt normaliseren voor jou op?
Hahaha, volgens mij kent Ger de beruchte productcodes van PostNL ook al...
Maar ik vraag me meer af hoe jij omgaat met het factuur adres.
De achterliggende beslissingsregels ken je dan waarschijnlijk ook al. Om te kunnen leveren op rekening heb je meer data nodig dan om een pakket te bezorgen.
Of dat te normaliseren is? Nee, nauwelijks helaas.
Uit:
Quote:
Why Normalization Failed to Become the
Ultimate Guide for Database Designers?
Ultimate Guide for Database Designers?
Quote:
“After all has been said and done, the main question could be: may we pronounce the divorce between normalization and
database designers ? Before answering the question, it is worth thinking at another one: have
they ever been married ? ”
database designers ? Before answering the question, it is worth thinking at another one: have
they ever been married ? ”
Gewijzigd op 22/04/2014 19:50:00 door Ger van Steenderen
Ja, laat maar komen... wat ik graag zou willen zien is dus hoe jij de gegevens opslaat van iemand die iets bestelt en zijn/haar adres(sen). Uiteraard mag je fictieve gegvens gebruiken.