Hallo
Ik ben bezig met een webshop temaken en zoch hier tussen de tuts en kwam terecht bij Opzet webwinkel en normalisatie (die ik al eerder had gelezen - echt handig).
Mijn vraag is of ik het tot nu toe goed doe of dit anders kan. Ik heb de volgende dingen toegevoegd:
-de prijs bij de bestelregel opslaan, voorkomt dat een order wijzigt als de prijs veranderd wordt
- adressen bij de order vastleggen, men kan tussen twee orders in verhuizen en dan zouden de historische gegevens niet meer kloppen
- categorieën en subcategorieën waarin de producten staan
Deze tips staat ook in de tut opzet webwinkel.
Nu de normalisatie(3) die ik nu heb:
3NV
BESTELLING
bestelnr
klantnr
besteldatum
status
BESTELDE_ARTIKELEN
bestelnr
artnr
aantal
artprijs (prijs van dat moment - want als de prijs verandert dan hebben we de oude nog)
ARTIKELEN
artnr
catnr
subcatnr
artnaam
artprijs_a (de actuele prijs)
HISTORY
id
woongegevens (alles gescheiden door komma's)
bestelnr
En hoe kan ik dit toepassen?:
- apart aflever en factuuradres, voor bedrijven meestal heel belangrijk: afleveren op een nevenvestiging en factureren aan de hoofdvestiging
postcode_cijfers
postcode_letters
is niet goed, een postcode bestaat namelijk (in NL) altijd uit 4 cijfers en 2 letters. Dit kun je dus onmogelijk gaan opknippen. Het is ook redelijk zinloos om de kolommen 'eerste_4_letters_van_de_voornaam' en 'overige_letters' aan te maken...
Wanneer 1 klant meerdere adressen kan hebben, dan heb je meerdere tabellen nodig. 1 tabel om het soort adres vast te stellen (hierin staat bv. factuuradres of afleveradres) en 1 tabel met de adresgegevens. Met een FK koppel je de hele zooi aan elkaar.
En wat adressen betreft, naast straatnaam en huisnummer bestaat er ook nog een toevoegsel, bv. 'a' of '3 hoog achter'.
1 telefoonnummer is eveneens wat weinig.
Prijzen van artikelen sla je op in een aparte tabel, met daarin ook de start- en einddatum van een prijs. Zo heb je de exacte geschiedenis wat betreft de prijzen. Uiteraard sla je ook het btw-tarief op, bruto inkoopprijs, netto inkoopprijs, bruto verkoop, netto verkoop, kortingen, etc. etc. etc.
Ik zou verder nog category in subcategory linken, en niet in het artikel zelf. Je zou eventueel nog subcategory en category kunnen samenvoegen waneer je een extra veld 'parentCategory' erbij aanmaakt. Voordeel is dat je dan oneindig diepe subcategorieën zou kunnen maken. Nadeel is dat je dan oneindig diepe subcategorieën zou kunnen maken :)
Edit: maar Frank, komt het dan ook voor dat er meerdere klanten op 1 en hetzelfde adres gevestigd zijn? Als dat niet zo is, dan lijkt mij een koppeltabel niet echt nodig. Dan zou een verwijzing naar klantid binnen het adres toch goed volstaan?
maar Frank, komt het dan ook voor dat er meerdere klanten op 1 en hetzelfde adres gevestigd zijn?
Verschillende bedrijven in 1 pand met 1 voordeur. Of particulier gezien: een student wonend in een studentenhuis met nog 10 anderen? Er is in ieder geval wel wat voor te zeggen.
@Jelmer/Blanche: Ik had er nog niet eens over nagedacht dat meerdere klanten hetzelfde adres konden hebben, staat ook nergens in mijn reactie. Maar het kan inderdaad wel voorkomen, ook in 1 gezin kun je diverse klanten hebben met hetzelfde adres.
Het is eveneens handig om de woonplaatsen in een aparte tabel te zetten, het heeft weinig zin om 4638 x 'amsterdam' (en alle varianten daarop) in de database weg te schrijven. Voor de straatnaam zou je dit ook kunnen overwegen, vrijwel ieder gat heeft wel een Hoofdstraat, Marktplein, etc.
Het is eveneens handig om de woonplaatsen in een aparte tabel te zetten, het heeft weinig zin om 4638 x 'amsterdam' (en alle varianten daarop) in de database weg te schrijven. Voor de straatnaam zou je dit ook kunnen overwegen, vrijwel ieder gat heeft wel een Hoofdstraat, Marktplein, etc.
Maar zou dat niet impliceren in je database dat de Hoofdstraat in Amsterdam dezelfde is als de Hoofdstraat in Zwaag Westeinde? Dat lijkt mij ook weer niet wenselijk.
Misschien is het een idee om straatnaam + woonplaats samen te nemen, of in ieder geval de straatnaam aan de woonplaats te verbinden. Want alleen dan heb je de mogelijkheid om ook iets met de straatnamen als data te doen. Want familie de Vries in de Hoofdstraat, dat lijkt mij incorrecte/incomplete data.
@Jelmer: Een straatnaam is maar een naam. En deze naam kan in diverse plaatsen voorkomen, lijkt mij geen probleem. Je hebt uiteraard wel een koppeltabel nodig, anders wordt het erg lastig en omslachtig om straatnaam en plaats aan elkaar te koppelen.
En vergeet niet dat je deze koppeling ook nodig hebt om de juiste postcode aan een locatie te koppelen! Postcode met huisnummer (en toevoegsel) is in principe voldoende om de locatie te vinden. De rest is eigenlijk niet meer nodig.
Wanneer je al deze gegevens (die door de gebruikers worden opgegeven) op de juiste manier aan elkaar knoopt, krijg je vanzelf een leuke postcode-database met allerlei aardige informatie. Ook leuk om nog even naar Google Maps te kijken, kun je ook de hoogte- en breedte nog even aan een locatie toevoegen...
Ik zal eens kijken of ik sommige punten wat hier staat kan toepassen, maar bj dat adressen enz snap ik nog even niet goed hoe ik dat moet doen. Kan iemand dat dadelijk toevoegen aan de nieuwe tabellen dik ik zo meteeen hier erbij post.
Tabel 'adrestypes':
id
omschrijving (bv. factuuradres of hoofdkantoor)
Tabel 'adressen'
id
id_klant (FK op klanten)
id_adrestype (FK op adrestypes)
...
...
Nu kan 1 klant een oneindig aantal adressen hebben.
Het gedoe met postcodes, woonplaatsen en straatnamen mag je zelf even uitwerken. Pak er pen en papier bij en ga aan de slag. Zo vreselijk moeilijk is het niet. Succes!
Nu zit ik al op de 11 tabellen en dadelijk komen nog veel meer dingen bij, zoals datum factuur, te betalen voor, wanneer is de order gegeven, enz.
Dingen die nu zijn verandert (met behulp van jullie tips natuurlijk):
Prijshistory, adreshistory, (telefoonhistory), meerdere adressen mogelijk, gesplits sturen (bv factuur naar hoofdkantoor en artikelen naar winkel), oneindig subcategorien, meerdere telefoons/fax mogelijk, makkelijker statussen geven/toevoegen
(achter alles moet het woord "mogelijk" komen want het ligt eraan hoe je het programmeert)
Procesgegevens, dus die hoeven er niet bij bij ARTPRIJS:
nettoInkoopprijs = brutoInkoopprijs x btwTarief
nettoVerkoopprijs = brutoVerkoopprijs x btwTarief
Weet iemand hoe ik een betere art beschrijving kan maken? Stel je verkoopt computers dan wil ik bij elke computer de zelfde opmaak hebben (cpu, hardschijf, geheugen, enz) en als ik dan boeken wil verkopen dus daar weer de gegevens bij alleboeken het zelfde (isbn, auteur, bladzijde enz)
Alvast bedankt :) ben nu lekker op dreef dit wordt een prima webshop (als eenmaal alle planning heb :))
DDragonz
