database layout webshop

[Ramon]

Hallo Allemaal,

Voor een eindexamen-opdracht voor school ben ik bezig met een webshop. Volgende week moeten we ons concept inleveren voor een go/no-go. Eerder hadden we de volgende layout bedacht

oude database layout

maar de leraar had hier nogal zijn twijfels over. Hij had het onder andere over factuurnummers, dit heb ik doorgevoerd, aangezien een nummer als 2005040211 toch voor de 'medewerkers' en voor de klanten makkelijker werkt als 00264562 ofzo
Daarnaast vertelde de leraar dat elk product wel los in de tabel bestelling kon staan, op de factuur kreeg je dat dan onder elkaar te zien. Maar op die manier dacht ik, sla je een heleboel info dubbel op, en ik dacht dat dat nou juist niet de bedoeling was?

Maargoed, naar aanleiding van het commentaar van de leraar ben ik op GoT rond gaan neuzen en vond dit topic: Shop Database Layout Overpeinzingen. Aan de hand van dat topic heb ik volgende schema in elkaar gezet(eindelijk... plaatjes!):



- een klant kan twee adressen hebben > een shipping en een billing adres.
- een product kan binnen meerdere categorieen vallen
- een klant kan meerdere betaalwijzes hebben opgeslagen in de db. bv: creditcard - overschrijving e.d. in het bestelprocess wordt hieruit een selectie gemaakt
- een bestelling kan meerdere producten bevatten

Is dit schema goed opgebouwd? Zijn er nog dingen die jullie erbij zouden willen?

Alvast bedankt

[Wacky]

Op zich ziet het er goed uit. Wat ik nog mis is bijvoorbeeld het artikelnummer bij de leverancier (dat scheelt een hoop gedoe als je iets bij de leverancier wil bestellen). Verder heb je nu bij de Leverancier een levertijd staan, maar kan dit niet per product verschillen? En kan een product niet door meerdere leveranciers geleverd worden? En waarom heb je de betaalwijze losgetrokken van de bestelling?

Edit:
Ik mis in de "producten in bestelling" (dit wordt meestal de orderregel genoemd trouwens) ook het aantal . Of kunnen klanten niet meer als 1 exemplaar van een product bestellen?

[ Voor 19% gewijzigd door Wacky op 03-04-2005 13:39 ]

[Compusmurf]

mij valt meteen iets op, shipping_adres_id, waarheen vewijst deze unieke waarde, dit geldt ook voor billing_adress_id en betaalwijze id.

Je pijltje staan beetje vreemd, nogmaal gaan bv van bestelling_id naar de kolom in de gelinkte tabel, je hebt dit bij andere kollommen staan.

Ik zou zeker wat doen aan de overzichtelijkheid van je lrs(logisch relationeel schema).

Als ik zo meer tijd heb zal een nog eens verder kijken of ik nog tips heb

[Compusmurf]

Er vallen me nog meer dingen op zie ik. Waarom zou je je billing en shipment adres niet toevoegen aan de bestelling zelf, gewoon koppelen naar een unieke kolom, het voordeel hiervan is is dat je dan per bestelling een ander adres kunt opgeven. Als ik dus bestel dan kan ik het nu naar de buren sturen etc.

[Mischa_NL]

Als je toch bezig bent:

Ik zie in je eerste opzet ook mogelijkheid tot een 2e telfoonnummer.
Maak daar dan ook een aparte tabel van zodat je meerdere telefoonnummers per klant kunt hebben!
of gewoon een extra column die null is als hij niet ingeuld is. Geeft hetzelfde effect

[alienfruit]

Misschien is het aardig om hier ook een "voorraad-systeem" aan te koppelen, zodat je de klant gaan vertellen hoeveel producten er nog op voorraad zijn, wanneer er nieuwe voorraad komt. Verder natuurlijk op het factuur bijv. een verwachte leverdatum voor producten die niet op voorraad zijn. Ook splits je de bestelling in delen qua facturen.

[Wacky]

Nog een tip: wat je nu gemaakt hebt is meer een functioneel ontwerp dan een technisch ontwerp. Als je dit ontwerp wil gaan implementeren ga je waarschijnlijk problemen tegen komen m.b.t. relaties. Bbijvoorbeeld 2 velden die een relatie hebben met een veld uit een andere tabel (bv. shipping/billing adres).

Of dit ontwerp bruikbaar is afhankelijk van welke database server je gaat gebruiken (MySQL, MSSQL, Access?).

[Johnny]

Factuurnummers moeten sinds 2004 oplopend zijn, dus geen datums er in verwerken want dan kun je weer allerlei problemen krijgen met de belastingsdienst.

[Ramon]

Wacky schreef op zondag 03 april 2005 @ 13:36:
Op zich ziet het er goed uit. Wat ik nog mis is bijvoorbeeld het artikelnummer bij de leverancier (dat scheelt een hoop gedoe als je iets bij de leverancier wil bestellen). Verder heb je nu bij de Leverancier een levertijd staan, maar kan dit niet per product verschillen? En kan een product niet door meerdere leveranciers geleverd worden? En waarom heb je de betaalwijze losgetrokken van de bestelling?

Edit:
Ik mis in de "producten in bestelling" (dit wordt meestal de orderregel genoemd trouwens) ook het aantal . Of kunnen klanten niet meer als 1 exemplaar van een product bestellen?

Dankjewel voor de reactie, ik zal het zo goed mogelijk proberen te antwoorden.

- Dit snap ik niet, artikelnummer bij de leverancier? Op de manier hoe het nu is kan je toch alle producten bij een leverancier makkelijk selecteren?
- Dat is een goede inderdaad, zal ik aanpassen
- In principe is dat geen prioriteit, maar hoe los je dat op? dmv een koppeltabel?
- Betaalwijze is los van de bestelling omdat de klant in principe meerdere betaalwijzes kan invoeren, hij zal immers niet altijd dezelfde manier betalen. De klant kan dan bij het bestellen een van zijn eerdere betaalwijzes selecteren om mee te betalen.
- Ook een goede, de klant moet inderdaad meerdere exemplaren van hetzelfde product kunnen bestellen. Pas ik ook aan.

Compusmurf schreef op zondag 03 april 2005 @ 13:38:
mij valt meteen iets op, shipping_adres_id, waarheen vewijst deze unieke waarde, dit geldt ook voor billing_adress_id en betaalwijze id.

Je pijltje staan beetje vreemd, nogmaal gaan bv van bestelling_id naar de kolom in de gelinkte tabel, je hebt dit bij andere kollommen staan.

Ik zou zeker wat doen aan de overzichtelijkheid van je lrs(logisch relationeel schema).

Als ik zo meer tijd heb zal een nog eens verder kijken of ik nog tips heb

shipping_adres_id en billing_adres_id verwijzen naar de tabel adres, en inderdaad zo kan je niet makkelijk even een cadeautje naar de buren sturen. Ik zal nog even kijken hoe dit op te lossen.

Betaalwijze_id gaat uiteraard naar de tabel betaalwijze, eigenlijk om de klant zo de keuze te bieden om eerder opgeslagen betaalmethodes te kiezen, en ze niet dubbel hoeven op te slaan.

Over de pijltjes, ik heb het geheel in ms visio in elkaar gezet als ik de pijltjes andersom doe dan wil visio er nog wel eens velden bijverzinnen...

Dankjewel voor de reactie ik zal nog even kijken of het overzichtelijker kan.

[Ramon]

alienfruit schreef op zondag 03 april 2005 @ 13:53:
Misschien is het aardig om hier ook een "voorraad-systeem" aan te koppelen, zodat je de klant gaan vertellen hoeveel producten er nog op voorraad zijn, wanneer er nieuwe voorraad komt. Verder natuurlijk op het factuur bijv. een verwachte leverdatum voor producten die niet op voorraad zijn. Ook splits je de bestelling in delen qua facturen.

goed plan, gaan we ook even naar kijken!

Wacky schreef op zondag 03 april 2005 @ 13:56:
Nog een tip: wat je nu gemaakt hebt is meer een functioneel ontwerp dan een technisch ontwerp. Als je dit ontwerp wil gaan implementeren ga je waarschijnlijk problemen tegen komen m.b.t. relaties. Bbijvoorbeeld 2 velden die een relatie hebben met een veld uit een andere tabel (bv. shipping/billing adres).

Of dit ontwerp bruikbaar is afhankelijk van welke database server je gaat gebruiken (MySQL, MSSQL, Access?).

We zijn verplicht MySQL te gebruik, ik weet niet of dat iets uitmaakt?
Hoe zou jij die shipping/billing adressen dan oplossen? Toch maar de adressen in de tabel Bestelling zetten?

Johnny schreef op zondag 03 april 2005 @ 13:57:
Factuurnummers moeten sinds 2004 oplopend zijn, dus geen datums er in verwerken want dan kun je weer allerlei problemen krijgen met de belastingsdienst.

Dat wist ik niet Dankjewel!

[ Voor 5% gewijzigd door Ramon op 03-04-2005 14:04 ]

[Wacky]

De betaalwijze van de order kun je toch gewoon d.m.v. een veld betaalwijze_id koppelen aan een tabel betaalwijzes? Ik snap niet waarom je dit weer koppelt aan de klant.

Meerdere leveranciers per product zul je inderdaad moeten oplossen met een koppeltabel. In deze koppeltabel neem je product_id en leverancier_id op. Ook kun je hier dus de levertijd voor dat product voor een bepaalde leverancier in opnemen, zoals bijvoorbeeld producten die de leverancier standaard niet op voorraad heeft. En ook de inkoopprijzen kun je hierin opnemen. Mocht je voorkeursleverancier een product niet op voorraad hebben kun je een selectie doen a.d.h.v. de inkoopprijs bij een andere leverancier. En in deze koppeltabel neem je dus ook het artikelnummer bij de leverancier op.

Succes!

[Wacky]

Ramon de Jesus schreef op zondag 03 april 2005 @ 14:01:
[...]
We zijn verplicht MySQL te gebruik, ik weet niet of dat iets uitmaakt?
Hoe zou jij die shipping/billing adressen dan oplossen? Toch maar de adressen in de tabel Bestelling

Ja die zou ik opslaan in de tabel Bestelling. Een factuur moet namelijk altijd weer opnieuw uit te draaien zijn met daarop de gegevens zoals die destijds ingevoerd zijn. Als nu een klant gaat verhuizen zal zijn billing en/of shipping adres veranderen en hiermee dus ook de billing/shipping adressen van alle eerdere bestellingen van die klant. En dat kan nooit de bedoeling zijn

Edit:
Misschien is het makkelijk om de pijltjes te veranderen in 1-op-1 en 1-op-veel relaties. Dat analyseert een stuk makkelijker en je ziet sneller of je relaties goed in elkaar steken.

[ Voor 13% gewijzigd door Wacky op 03-04-2005 14:17 ]

[Verwijderd]

Je moet de prijs ook in "producten in bestelling" zetten, anders kloppen de waarden van bestellingen niet meer als er productprijzen veranderen.

Afleveradres moet ook in de bestellingen tabel, voor het geval er een adreswijziging plaatsvindt (indien dat mogelijk is).

Dit geldt wellicht voor nog wat meer gegevens. Een bestelling is een soort "snapshot" van een setje gegevens, dus zul je bepaalde waarden moeten overnemen, in plaats van vertrouwen op een relatie..

[Ramon]

Wacky schreef op zondag 03 april 2005 @ 14:04:
De betaalwijze van de order kun je toch gewoon d.m.v. een veld betaalwijze_id koppelen aan een tabel betaalwijzes? Ik snap niet waarom je dit weer koppelt aan de klant.

Meerdere leveranciers per product zul je inderdaad moeten oplossen met een koppeltabel. In deze koppeltabel neem je product_id en leverancier_id op. Ook kun je hier dus de levertijd voor dat product voor een bepaalde leverancier in opnemen, zoals bijvoorbeeld producten die de leverancier standaard niet op voorraad heeft. En ook de inkoopprijzen kun je hierin opnemen. Mocht je voorkeursleverancier een product niet op voorraad hebben kun je een selectie doen a.d.h.v. de inkoopprijs bij een andere leverancier. En in deze koppeltabel neem je dus ook het artikelnummer bij de leverancier op.

Succes!

- Ik wil het namelijk mogelijk maken dat ingelogde klanten betaalmethodes van te voren kunnen opslaan in de database via een preferences pagina oid.
- Dat is een goede suggestie. Ga ik mee aan de slag.

Verwijderd schreef op zondag 03 april 2005 @ 14:10:
Je moet de prijs ook in "producten in bestelling" zetten, anders kloppen de waarden van bestellingen niet meer als er productprijzen veranderen.

Afleveradres moet ook in de bestellingen tabel, voor het geval er een adreswijziging plaatsvindt (indien dat mogelijk is).

Dit geldt wellicht voor nog wat meer gegevens. Een bestelling is een soort "snapshot" van een setje gegevens, dus zul je bepaalde waarden moeten overnemen, in plaats van vertrouwen op een relatie..

Ik snap het idee Dankjewel

[alienfruit]

Moet je zo'n opdracht nou eigen maken voor een examen in het middelbaar onderwijs? Lijkt mij een beetje een gekke opdracht voor een eindexamen.

[Wacky]

Ramon de Jesus schreef op zondag 03 april 2005 @ 14:30:
- Ik wil het namelijk mogelijk maken dat ingelogde klanten betaalmethodes van te voren kunnen opslaan in de database via een preferences pagina oid.

Koppel dan de betaalwijze van de order in de tabel Bestelling en sla de voorkeur van de klant op in de tabel Klanten

Nu moet je namelijk voor iedere klant die zich aanmeld ook een nieuw record toevoegen in die betaalwijze tabel. Dat is niet echt (echt niet) genormaliseerd.

[ Voor 18% gewijzigd door Wacky op 03-04-2005 14:47 ]

[Ramon]

alienfruit schreef op zondag 03 april 2005 @ 14:38:
Moet je zo'n opdracht nou eigen maken voor een examen in het middelbaar onderwijs? Lijkt mij een beetje een gekke opdracht voor een eindexamen.

is dat een belediging? iemand van 21 die nog op het middelbaar zit?

Nee dit is een MBO opdracht.

[Ramon]

Wacky schreef op zondag 03 april 2005 @ 14:45:
[...]


Koppel dan de betaalwijze van de order in de tabel Bestelling en sla de voorkeur van de klant op in de tabel Klanten

Nu moet je namelijk voor iedere klant die zich aanmeld ook een nieuw record toevoegen in die betaalwijze tabel. Dat is niet echt (echt niet) genormaliseerd.

maar op die manier is het niet mogelijk meerdere betaalmethodes per klant op te slaan, toch? En dat zou ik wel graag willen doen.

[alienfruit]

Nee, tuurlijk niet Ik dacht misschien is dit weer een van die rare opdrachten die je in de Tweede Fase krijgt

[Wacky]

Ramon de Jesus schreef op zondag 03 april 2005 @ 15:03:
[...]
maar op die manier is het niet mogelijk meerdere betaalmethodes per klant op te slaan, toch? En dat zou ik wel graag willen doen.

Meerdere betaalmethodes per klant? De klant kan toch kiezen uit de betaalmethodes die je aanbiedt? Op de manier waarop je het nu in elkaar hebt zitten heb je nergens een tabel waarin de beschikbare betaalwijzes staan opgeslagen!

Even een voorbeeldje:

Ik ga er vanuit dat je bijvoorbeeld 3 betaalwijzes gaat aanbieden: incasso, rembours en vooruitbetaling. Deze sla je dus apart op in de tabel Betaalwijzes. Vanuit de tabel bestelling koppel je de gebruikte betaalwijze. De voorkeur van de klant sla je op in de tabel Klant.

En klaar is Ramon

[Soultaker]

Ramon de Jesus schreef op zondag 03 april 2005 @ 13:30:
Daarnaast vertelde de leraar dat elk product wel los in de tabel bestelling kon staan, op de factuur kreeg je dat dan onder elkaar te zien. Maar op die manier dacht ik, sla je een heleboel info dubbel op, en ik dacht dat dat nou juist niet de bedoeling was?

Ik neem aan dat je bedoeld dat de velden van 'product' dan ook in 'producten in bestelling' komen te staan? Dat is geen hele gekke suggestie, sterker nog, ik heb zoiets in de praktijk gebruikt. Het is inderdaad jammer dat je gegevens dupliceert, maar het grote voordeel is dat een eenmaal gemaakte bestelling niet meer veranderd.

Als in jouw huidige model de prijs van een product gewijzigd wordt (of vervelender nog, als het product verwijderd wordt) dan worden ook de totalen van alle bestellingen aangepast. Dat is nogal vervelend als een bestelling al betaald is bijvoorbeeld. Een klant staat vreemd te kijken als 'ie een bestelling per e-mail bevestigd krijgt en later weer een paar euro meer moet betalen. Daarom is het aan te raden om er op de een of andere manier voor te zorgen dat een aangemaakte bestelling definitief is.

Dat hoeft niet per se door die bestelde producten te kopiëren. Een alternatief is de kritieke eigenschappen (zoals de prijs) van elk product per periode aan te geven, zodat je de prijs van een product op een bepaald tijdstip kunt opvragen. (Producten verwijder je dan ook nooit meer.) Een andere, nog rigoreuzere aanpak is om het wijzigen van producten onmogelijk te maken, maar er wel voor te zorgen dat producten verborgen kunnen worden. Als je bijvoorbeeld de prijs van het product wijzigt, maak je een heel nieuw product aan, zodat referenties naar het oude product gelijk blijven.

[Verwijderd]

Waarom heb je een klant_id, je hebt toch al een username...

[Wacky]

Verwijderd schreef op zondag 03 april 2005 @ 16:48:
Waarom heb je een klant_id, je hebt toch al een username...

Klantnummers zijn verplicht volgens de belasting dienst Het is wellicht een beter idee om voor de username het klantnummer te nemen

[JHS]

Wacky schreef op zondag 03 april 2005 @ 15:09:
[...]Ik ga er vanuit dat je bijvoorbeeld 3 betaalwijzes gaat aanbieden: incasso, rembours en vooruitbetaling. Deze sla je dus apart op in de tabel Betaalwijzes. Vanuit de tabel bestelling koppel je de gebruikte betaalwijze. De voorkeur van de klant sla je op in de tabel Klant.

Belangrijker is lijkt me om de keuze per order op te slaan. En eventueel een voorkeur welke dan standaard geselecteerd wordt als de klant een order gaat plaatsen. *

Soultaker: De door jou voorgestelde twee alternatieven lijken me ingewikkelder om te implementeren, begrijpen en ook minder logisch dan wat Cheetah suggereerd. Een deel van de eigenschappen van een bestelling zijn eigenlijk inderdaad een soort snapshot van een deel van de eigenschappen van een product op een bepaald moment. Dus ik zou het ook zo implementeren .

edit:

Ah, dat bedoelde hij dus ook...

[ Voor 9% gewijzigd door JHS op 03-04-2005 17:08 ]

[Wacky]

JHS schreef op zondag 03 april 2005 @ 17:01:
[...]
Belangrijker is lijkt me om de keuze per order op te slaan. En eventueel een voorkeur welke dan standaard geselecteerd wordt als de klant een order gaat plaatsen.

Dat bedoelde ik dus

[Ramon]

Nou ik heb m'n hersenen er nog even een nachtje over laten kraken en ik snap nog steeds niet wat jullie bedoelen met de betaalmethodes. Ik heb een schetsje gemaakt om mijn idee wat beter proberen uit te leggen, ik hoop dat jullie zo snappen wat ik probeer te doen?



Wat ik dus wil is dat klanten voor alle betaalmethodes die ik aanbiedt (lijstje kan nog veranderen) gegevens kunnen opslaan, dus ze kunnen hun creditcardnummer opslaan en hun rekeningnummer voor een acceptgiro betaling.

Ik heb nu ook shipping en billing adres in de tabel bestelling gezet maar ik heb het idee dat dit niet erg efficient is? Is het niet beter om deze adressen toch uit de tabel adres te linken, maar dan te zorgen dat wanneer een klant zijn adres wil veranderen, er een nieuwe record in de tabel adres wordt aangemaakt zodat de koppeling vanuit die ene bestelling goed blijft?

[Soultaker]

JHS schreef op zondag 03 april 2005 @ 17:01:
Soultaker: De door jou voorgestelde twee alternatieven lijken me ingewikkelder om te implementeren, begrijpen en ook minder logisch dan wat Cheetah suggereerd. Een deel van de eigenschappen van een bestelling zijn eigenlijk inderdaad een soort snapshot van een deel van de eigenschappen van een product op een bepaald moment. Dus ik zou het ook zo implementeren .

Ik noemde Cheetah's optie ook, sterker nog, die heeft mijn voorkeur. De andere twee opties waren mogelijke alternatieven.

Het probleem met slechts een deel van de productinformatie in de 'producten in bestelling'-tabel zetten, is dat je dan nog steeds een verwijzing moet hebben naar de echte producten, en dan kun je die dus nog steeds niet zomaar uit het assortiment verwijderen. Daar moet je dus hoe dan ook iets op verzinnen, als je 't zo wil oplossen! Vandaar mijn voorstel om het hele product te kopiëren zodat die hele referentie naar de procuten-tabel eruit kan.

[ Voor 8% gewijzigd door Soultaker op 04-04-2005 12:39 ]

[JHS]

Soultaker: Ok . Maar bijvoorbeeld een afbeelding van een product die je alleen laat zien als iemand iets gáát bestellen hoeft lijkt mij bijvoorbeeld niet te worden overgenomen in een individuele order .

Ramon de Jesus: Persoonlijk zou ik zeggen dat je voor die adressen ongeveer hetzelfde hebt als bij de betaalmogelijkheden . Je hebt een pool aan adressen, een klant kan zijn primaire adres ("voorkeur") opgeven, en per order kan hij elk adres (ook een nieuw) invoeren .

[raptorix]

Verwijderd schreef op zondag 03 april 2005 @ 14:10:
Je moet de prijs ook in "producten in bestelling" zetten, anders kloppen de waarden van bestellingen niet meer als er productprijzen veranderen.

Afleveradres moet ook in de bestellingen tabel, voor het geval er een adreswijziging plaatsvindt (indien dat mogelijk is).

Dit geldt wellicht voor nog wat meer gegevens. Een bestelling is een soort "snapshot" van een setje gegevens, dus zul je bepaalde waarden moeten overnemen, in plaats van vertrouwen op een relatie..

Een klasieke instinker die iedereen die zoiets bouwt bijna maakt
Nog mooier is het om een historische table bij te houden, maar dat maakt het gelijk stuk lastiger.

Een collega van me heeft een boekje waarin de problemen rond het opslaan van historische data wordt uitgelegt. Ik zal eens vragen hoe dat boekje heet.

[bRight]

In tabel 'bestelling' mis ik nog een opmerkingenveld. kan erg handig zijn
Daarnaast is het verstandig om ook een BTW percentage in deze tabel op te nemen.
Die kan in de loop der tijd misschien nog eens wijzigen..
Heb je trouwens al nagedacht over verzendmethoden? Ik zie alleen betaalmethoden
(Let erop dat je in geval van rembours overlap krijgt in verzend-betaalmethode)