normalisate- Is dit goed...?
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)
KLANTEN
klantnr
voornaam
tussenvoegsel
achternaam
straat
huisnr
postcode_cijfers
postcode_letters
woonplaats
telefoonnr
emailadres
wachtwoord
CATEGORIE
catnr
catnaam
catbeschrijving
SUBCATEGORIE
subcatnr
subcatnaam
subcatbeschrijving
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
Alvast bedankt
DDragonz
Tabellen
Orders:
OrderID
ClientID
ArticleID
Status
GPriceTotal
Notice
Clients:
ClientID
Name
Prename
Adress
Postal
City
PasswordMD5
Articles:
ArticleID
Name
Picture
Price
Description
GenreID
Genres:
GenreID
GName
Keywords
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.
Succes!
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?
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
Quote:
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.maar Frank, komt het dan ook voor dat er meerdere klanten op 1 en hetzelfde adres gevestigd zijn?
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.
Frank schreef op 11.06.2007 11:26:
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.
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.
id
naam
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!
huisnummer
straatToevoegsel
postcode
woonplaats
TELEFOONS
id_telefoon
id_klantNummer
id_telefoontype
nummer
ARTIKELEN
id_artNummer
id_catNummer
artNaam
artPrijs
CATEGORIE
id_catNummer
catParent
catNaam
catBeschrijving
ADRESTYPES
id_adrestype
omschrijving
TELEFOONTYPES
id_telefoontype
omschrijving
STATUSTYPES
id_status
omschrijving
ARTPRIJS
id_artprijs
btwTarief
brutoInkoopprijs
brutoVerkoopprijs
korting
starttijd
eindtijd
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