normalisate- Is dit goed...?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

DDragonz

DDragonz

10/06/2007 23:43:00
Quote Anchor link
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)

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
 
PHP hulp

PHP hulp

07/11/2024 12:15:24
 
Jefffrey

Jefffrey

10/06/2007 23:49:00
Quote Anchor link
Wow dat zijn veel tabellen. Ik ben ook een webshop anan het maken voor school en ik heb deze tabellen :)

Tabellen

Orders:

OrderID
ClientID
ArticleID
Status
GPriceTotal
Notice

Clients:

ClientID
Name
Prename
Adress
Postal
City
Email
PasswordMD5

Articles:

ArticleID
Name
Picture
Price
Description
GenreID

Genres:

GenreID
GName
Keywords
 
Frank -

Frank -

11/06/2007 01:38:00
Quote Anchor link
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.

Succes!
 
Jelmer -

Jelmer -

11/06/2007 08:32:00
Quote Anchor link
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?
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
 
Joren de Wit

Joren de Wit

11/06/2007 10:39:00
Quote Anchor link
Quote:
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.
 
Frank -

Frank -

11/06/2007 11:26:00
Quote Anchor link
@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.
 
Jelmer -

Jelmer -

11/06/2007 12:58:00
Quote Anchor link
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.
 
Frank -

Frank -

11/06/2007 13:11:00
Quote Anchor link
@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...
 
DDragonz

DDragonz

12/06/2007 17:59:00
Quote Anchor link
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.
 
Frank -

Frank -

12/06/2007 18:03:00
Quote Anchor link
Tabel 'klanten':
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!
 
DDragonz

DDragonz

12/06/2007 21:21:00
Quote Anchor link
straat
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
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.