Database ontwerp simpele webshop

[nowherebound123]

Tweakers,

Ik ben bezig met het opstellen van een database ontwerp voor een simpele webshop die ik aan het maken ben.

Het volgende is wat ik nu heb liggen:



userActivated is hier een veld wat een 1 of een 0 kan bevatten, bij een 1 heeft de gebruiker geactiveerd.

userAdmin kan ook 1 of 0 bevatten, simpel rechten systeem dus.

productCat = productCategory

basketOrderDate wordt pas ingevuld wanneer iemand afrekent, is die nog null dan is het dus nog een winkelwagen artikel.

basketCode wil ik gebruiken als code die men als betalingskenmerk moet gebruiken bij het overboeken van het geld.

Ik zit nog met het probleem dat het kan zijn dat producten in meerdere kleuren en of maten kunnen komen, hoe kan ik zoiets het beste aanpakken?

Zitten er verder nog dingen in die ik beter anders zou kunnen aanpakken?

[DamadmOO]

Dit is wel een hele primitieve versie van een webshop. Ik kan je nu al garanderen dat je de mist in gaat met je productgroepen als wel dat klanten een bezoekadres, factuuradres, verzendadres willen hebben. Verder zou ik je basket opslitsen in algemene informatie en basketitems (en voeg dan ook meteen een ordered_quantity toe).

Waarom ontwikkel je dit zelf? Kan je niet gewoon een open source e-commerce systeem gebruiken? Want als ik je huidige opzet zie dan gaat het nog lang duren voordat je iets goeds klaar hebt.

[nowherebound123]

DamadmOO schreef op woensdag 27 mei 2009 @ 18:46:
Dit is wel een hele primitieve versie van een webshop. Ik kan je nu al garanderen dat je de mist in gaat met je productgroepen als wel dat klanten een bezoekadres, factuuradres, verzendadres willen hebben. Verder zou ik je basket opslitsen in algemene informatie en basketitems (en voeg dan ook meteen een ordered_quantity toe).

Waarom ontwikkel je dit zelf? Kan je niet gewoon een open source e-commerce systeem gebruiken? Want als ik je huidige opzet zie dan gaat het nog lang duren voordat je iets goeds klaar hebt.

quantiteit, hele goeie, dankje

Hoezo ga ik de mist in met productgroepen?

Verschillend factuur en verzend adres, ook een goeie idd, zal ik eens wat op bedenken.

Ik doe dit zelf omdat ik het leuk vindt om te doen.

Nog suggesties voor meerdere kleuren/maten van artikelen?

[SinergyX]

Ik denk dat je huisnummer mist, of die moeten ze bij userStreet invullen?

Al ben ik het deels met Damad eens, maar met zelf bouwen leer je er natuurlijk ook aardig wat mee

Verder, als iemand nu 2 bestellingen plaats, hoe onderscheid je die in je shop_basket? Op basis van OrderDate? Dan zou ik eerder een tabel erbij zetten met de werkelijke orders, zodat je basket de 'temp' bak is (niet iedereen die dingen in de basket zet, gaat het ook werkelijk bestellen). Besteld hij daadwerkelijk kan je via die tabel er een auto-inc order ID aan geven, makkelijker terug te vinden.

[ Voor 33% gewijzigd door SinergyX op 27-05-2009 18:59 ]

[soulrider]

bezoek eens enkele webshops die hetzelfde verkopen als jij, bekijk even waarop artikels, klanten enzo opdeelbaar zijn. En ook welke gegevens zekers van belang zijn in de winkelkar.

Ja kan ook steeds even een opensource variant bekijken en zien hoe zij hun database opdelen, en dan bedenken waar jij in de mist gaat, of waarom je het anders doet.

enkele vragen die je al kunne helepne:
- verkoop je goederen die bv per kleur aanpasbaar zijn, zoals t-shirts met opschriften?
- maak je ook direct een koppeling naar je voorraad en inkoop?
- verkoop je uit voorraad, of resel je producten (en bestel je bij je leverancier zodra jij een bestelling binnenhebt - dus zonder eigen voorraad) ?
(ergens een koppeling nodig tussen uw eigen artikel nummers en die van je leverancier, alsook omschrijvingen enzo - want je wilt dat niet altijd gaan opzoeken)
- laat je aparte (verschillende) factuur- en verzendadressen toe?
- ga je ook staffelkorting en/of "vaste klants"-korting toelaten (of later misschien?)
- ga je ook je facturen (en dus daarmee ook je boekhouding) apart opslaan?
(altijd makkelijk als een klant verwijst naar zijn factuur wegens foute afrekening, of omdat je die nodig hebt wegens garantie claims of omdat de klant zijn koop-op-afstand-"garantie" wilt gebruiken)
- ga je een klant toelaten online zijn vorige facturen terug op te zoeken en eventuele status qua bestelling/verzending op te vragen? kan die bezoeker ook zijn winkelkar opslaan om later simpel te kunnen bestellen? (omdat ie alles in 1x wilt maar ook nog niet wilt betalen tot ie ziet dat alles beschikbaar is en direct verzonden kan worden?)
- Ga je deels beschikbare bestellingen opsplitsen in 'beschikbaar en wordt direct verstuurd en het niet voorradige komt achterna' tegenover 'alles wordt pas verzonden als alles in voorraad is' en hoe voorkom je dan dat het reeds voorradige uitverkocht is tegen dat de rest van de bestel terug in voorraad is ?
(maw stock beheer en -reservatie?)
- ....

best bv ook je product categorie in aparte tabel, zodat je daar eenvoudig de categorie omschrijving enzo kunt beheren. (eventueel in verschillende talen) (anders heb je op den duur productcat 'moederborden' en 'motherbords' of 't-shirts' en 'T-shirt')

andere vragen kan je je zelf wel stellen eh
(maw; je analyse heeft nog serieuse gaten en qua normalisatie ga je je ook eens even moeten inlezen)

[ Voor 26% gewijzigd door soulrider op 27-05-2009 19:16 ]

[Woy]

Aangezien het meer over het design gaat past deze beter in SEA

PRG -> SEA

[nowherebound123]

SinergyX schreef op woensdag 27 mei 2009 @ 18:57:
Ik denk dat je huisnummer mist, of die moeten ze bij userStreet invullen?

Al ben ik het deels met Damad eens, maar met zelf bouwen leer je er natuurlijk ook aardig wat mee

Verder, als iemand nu 2 bestellingen plaats, hoe onderscheid je die in je shop_basket? Op basis van OrderDate? Dan zou ik eerder een tabel erbij zetten met de werkelijke orders, zodat je basket de 'temp' bak is (niet iedereen die dingen in de basket zet, gaat het ook werkelijk bestellen). Besteld hij daadwerkelijk kan je via die tabel er een auto-inc order ID aan geven, makkelijker terug te vinden.

Je hebt gelijk, ik heb nu een aparte tabel voor daadwerkelijke orders aangemaakt.

[nowherebound123]

soulrider schreef op woensdag 27 mei 2009 @ 19:08:
bezoek eens enkele webshops die hetzelfde verkopen als jij, bekijk even waarop artikels, klanten enzo opdeelbaar zijn. En ook welke gegevens zekers van belang zijn in de winkelkar.

Ja kan ook steeds even een opensource variant bekijken en zien hoe zij hun database opdelen, en dan bedenken waar jij in de mist gaat, of waarom je het anders doet.

enkele vragen die je al kunne helepne:
- verkoop je goederen die bv per kleur aanpasbaar zijn, zoals t-shirts met opschriften?

In principe wel ja, daarom vroeg ik ook al wat de beste manier zou zijn om zo iets aan te pakken.

- maak je ook direct een koppeling naar je voorraad en inkoop?

Doe ik in principe met het productStock veld.

- verkoop je uit voorraad, of resel je producten (en bestel je bij je leverancier zodra jij een bestelling binnenhebt - dus zonder eigen voorraad) ?

Uit voorraad, wederom productStock

- laat je aparte (verschillende) factuur- en verzendadressen toe?

Dat ga ik in eerste instantie niet doen, de shop is zowiezo ZEER kleinschalig, als er meer dan 15 producten inkomen zou het mij verbazen.

Als ik een aparte tabel zou maken voor categorieen, hoe zou ik die dan het beste kunnen toewijzen aan een product. In het productCat veld gewoon alle categorie id's opslaan gescheiden door komma of kan dat slimmer?

[DamadmOO]

nils.kuijpers schreef op woensdag 27 mei 2009 @ 19:36:
Als ik een aparte tabel zou maken voor categorieen, hoe zou ik die dan het beste kunnen toewijzen aan een product. In het productCat veld gewoon alle categorie id's opslaan gescheiden door komma of kan dat slimmer?

Komma gescheiden moet je NOOIT aan beginnen.

Maak gewoon 3 tabellen:

tblProducts
Product_ID
Product_Name

tblGroups
Group_ID
Group_Name

tblProductsGroupsCoupling
Product_ID
Group_ID

Of iets dergelijks.

[nowherebound123]

DamadmOO schreef op woensdag 27 mei 2009 @ 19:40:
[...]

Komma gescheiden moet je NOOIT aan beginnen.

Maak gewoon 3 tabellen:

tblProducts
Product_ID
Product_Name

tblGroups
Group_ID
Group_Name

tblProductsGroupsCoupling
Product_ID
Group_ID

Of iets dergelijks.

Ik bedenk me zojuist dat een product in mijn situatie maar in 1 categorie kan staan, dus ik zet gewoon die ene ID in het productCat veld.

Huidige status:

http://cabdatabase.com/ontwerp.xls

[ Voor 5% gewijzigd door nowherebound123 op 27-05-2009 20:02 ]

[creator1988]

Algemene opmerking. Waarom in vredesnaam je tabelnamen prefixen voor elk veld (als in categorieNaam)? Onnodig en maakt het onnodig ingewikkeld. Tevens foutgevoelig als je straks aan het ontwikkelen bent.

[BCC]

En waarom ben je voor de 100.000ste keer het wiel aan het uitvinden ? Hobby, School of gewoon eigenwijsheid ?

[Eriksk]

Even iets algemeens:
Houd er rekening mee dat je de gegevens dubbel opslaat in je ordertabel zoals de prijs van het product.
Heb je ook al nagedacht over btw? En houd er rekening mee dat ook het btw-percentage kan veranderen

[Verwijderd]

Een huisnummer is leuk, maar ik zou dat niet in een integer veld opslaan. Het komt bijvoorbeeld regelmatig voor dat iemand op 38c woont.

[nowherebound123]

@creator: Weet ik eigenlijk niet, oude gewoonte

@BCC: Hobby en eigenwijsheid

@Eriksk: Wat bedoel je precies?

@Stierenoog: Bedankt voor de tip, had dat zelf ook al bedacht en is reeds aangepast.

[Eriksk]

Een klant koopt wat op 29-05-2009:
5 * DELL D630 van 500 p/s excl 19% btw
Totaal (incl. btw): 2975,-

In jou ontwerp heb je een referntie opgenomen naar het product.
Op 30-05-2009 beslis jij om de prijs te verhogen (525 euro), er komt een staatsgreep en Mini-Me grijpt de macht en verhoogt de BTW naar 21%.

Op 1 juni vraagt de klant opnieuw zijn order-overzicht (of hij al betaald heeft of niet laten we buiten beschouwing). Het totaal is dan door jou db-ontwerp: 5*525*1.21 = 3176.25

Je kunt dus nooit een historie bijhouden van orders! Bij een shoppingcart maakt dat niet uit, want er is geen overeenkomst.

Snap je?

[SiErRa]

Kleine optimalisatie maak van de userActivated en userAdmin velden een bit/bool veld ipv. een int.

Niet alleen vanwege de paar bespaarde bytes, maar ook zodat niemand direct in de db een 2 in zet en je applicatie straks stuk gaat

Verwijderd schreef op vrijdag 29 mei 2009 @ 10:24:
Een huisnummer is leuk, maar ik zou dat niet in een integer veld opslaan. Het komt bijvoorbeeld regelmatig voor dat iemand op 38c woont.

Of huisnummer een int laten en een varchar huisnummerToevoeging veld toevoegen, want er zijn echt rare toevoegingen, "tegenover *huisnummer*" voor woonboten bijvoorbeeld.

[Johnny]

Voor de prijs van je product kun je ook beter het datatype DECIMAL(8,2) gebruiken waarbij dus geen afrondingsfouten kan hebben en maximaal maar 2 decimalen. Ook moet je bij een prijs altijd een valuta vermelden, omdat je nu niet weet of het dollars, euro's of guldens zijn. Gebruik dan ook de gestandardiseerde valutacodes, dat kan je overginds ook voor het land doen, want nu kun je mensen uit "Nederland", "Holland" of "(The) Netherlands" hebben terwijl "NL" een stuk duidelijker is.

Wachtwoorden moet je ook eerst hashen, het kan zijn dat je het al van plan was, maar aangezien je een VARCHAR gebruikt noem ik het toch nog even. Een hash heeft altijd dezelfde lengte dus CHAR(40) voor een SHA-1 hash zou genoeg zijn, maar je kan deze ook in BINARY(20) opslaan (dus niet omzetten naar hexadecimale ASCII).

[Nick_S]

SiErRa schreef op dinsdag 09 juni 2009 @ 15:37:
Of huisnummer een int laten en een varchar huisnummerToevoeging veld toevoegen, want er zijn echt rare toevoegingen, "tegenover *huisnummer*" voor woonboten bijvoorbeeld.

Dan zou je dus een huisnummerPrefix en een huisnummerPostfix moeten hebben, aangezien t.o. ervoor staat en 'c' erachter. Een huisnummer als int is alleen handig als je erop wil gaan sorteren, want ik neem aan dat je er geen berekeningen mee gaat doen.

[BCC]

Johnny schreef op dinsdag 09 juni 2009 @ 15:50:
Voor de prijs van je product kun je ook beter het datatype DECIMAL(8,2) gebruiken waarbij dus geen afrondingsfouten kan hebben en maximaal maar 2 decimalen.

Altijd werken in centen met geld in een database (dus integers)! Anders krijg je altijd gezeik met afrondingen die in de database anders zijn dan in je presentatielaag. Met floats is dit altijd een probleem, met decimals soms maar met centen in integers kan er nooit iets mis gaan. Alle financiele pakketten waar ik tot nu toe mee gewerkt heb doen dit ook.

[ Voor 32% gewijzigd door BCC op 09-06-2009 23:57 ]

[Verwijderd]

BCC schreef op dinsdag 09 juni 2009 @ 23:48:
[...]

Altijd werken in centen met geld in een database (dus integers)! Anders krijg je altijd gezeik met afrondingen die in de database anders zijn dan in je presentatielaag. Met centen kan er nooit iets mis gaan. Alle financiele pakketten waar ik tot nu toe mee gewerkt heb doen dit ook.

nooit met 10e centen gewerkt ?

[BCC]

Heb je ooit een factuur gestuurd / ontvangen met 10de centen? Maar 10de centen is ook prima, zolang het maar een integer blijft.

[ Voor 35% gewijzigd door BCC op 10-06-2009 00:10 ]

[Verwijderd]

BCC schreef op woensdag 10 juni 2009 @ 00:09:
Heb je ooit een factuur gestuurd / ontvangen met 10de centen? Maar 10de centen is ook prima, zolang het maar een integer blijft.

na, toevallig niet ontvangen/verstuurd maar wel verwerkt.
Er zijn genoeg voorbeelden te vinden waarbij zaken met 10e van centen worden verrekend.
En het wordt wat lastig om alles door elkaar te gebruiken in sommige gevallen. Dus je oplossing is op zich niet verkeerd maar zeker niet altijd van toepassing.

[ Voor 17% gewijzigd door Verwijderd op 10-06-2009 00:13 ]

[BCC]

Geld is prima, zolang je het maar niet als komma getallen opslaat

[ Voor 10% gewijzigd door BCC op 10-06-2009 00:14 ]

[The Eagle]

nils.kuijpers schreef op vrijdag 29 mei 2009 @ 11:49:
@creator: Weet ik eigenlijk niet, oude gewoonte

@BCC: Hobby en eigenwijsheid

@Eriksk: Wat bedoel je precies?

@Stierenoog: Bedankt voor de tip, had dat zelf ook al bedacht en is reeds aangepast.

Mag ik aan die huisnummerdiscussie dan nog toevoegen dat je voor het toevoegingen veld bij Nederlandse huisnummers een characterveld nodig hebt van minimaal 6 karakters lang? Ja inderdaad, er zijn toevoegingen van 6 karakters lang. Een toevoeging als "5 hoog" bijvoorbeeld. Wordt echt gebruikt (been there, done that, zelfs een van de developmentteams van Oracle op attent moeten maken via een case).

[Verwijderd]

The Eagle schreef op woensdag 10 juni 2009 @ 00:14:
[...]

Mag ik aan die huisnummerdiscussie dan nog toevoegen dat je voor het toevoegingen veld bij Nederlandse huisnummers een characterveld nodig hebt van minimaal 6 karakters lang? Ja inderdaad, er zijn toevoegingen van 6 karakters lang. Een toevoeging als "5 hoog" bijvoorbeeld. Wordt echt gebruikt (been there, done that, zelfs een van de developmentteams van Oracle op attent moeten maken via een case).

idd, of t/o 11 (tegen over nummer 11)

[Eriksk]

Geld opslaan als integers? Sure...
Dus als je hondersten van centen wilt opslaan krijg je je bij een euro dus de waarde 1000? Het is al wel een jaartje geleden dat ik in de Navision database heb gekeken, maar ik weet wel zeker dat zij bedragen echt niet als integers opslaan.

In MS SQL gebruik je gewoon het datatype Money. Gebruik anders een datatype die het niet bij benadering opslaat (zoals floats) maar een numeric of decimal.

/edit:
Als je met geld werkt, is het redelijk standaard dat je met 4 cijfers achter de komma werkt.

[ Voor 10% gewijzigd door Eriksk op 10-06-2009 07:44 ]

[BCC]

datatype Money and rounding problems:
http://groups.google.com/...nk=st&q=#8926f7fa31fa4832

Gebruik anders een datatype die het niet bij benadering opslaat (zoals floats) maar een numeric of decimal.

Daar ben ik het helemaal mee eens, maar decimal heeft in sommige gevallen ook rounding problemen.

Eriksk schreef op woensdag 10 juni 2009 @ 07:43:
Als je met geld werkt, is het redelijk standaard dat je met 4 cijfers achter de komma werkt.

Voor een financieel pakket, ja, maar het gaat hier om een webshop;

[ Voor 60% gewijzigd door BCC op 10-06-2009 09:31 ]

[Eriksk]

datatype Money and rounding problems:
http://groups.google.com/...nk=st&q=#8926f7fa31fa4832
Daar ben ik het helemaal mee eens, maar decimal heeft in sommige gevallen ook rounding problemen.

Ah zo ja... Ik dacht meer aan simpele CRUD statements. Ik laat het rekenwerk liever over aan de applicatie zelf en niet aan de database. Doordat je de DB gebruikt voor opslag en niet voor zulke logica, zul je hier niet tegen aan lopen.

Voor een financieel pakket, ja, maar het gaat hier om een webshop;

Dat wil niet zeggen dat je het daarom niet goed hoeft te doen. Altijd handig om het direct goed te doen (toekomst: koppelen met financiële pakketten?)

[Keneo]

deze semester zelf een webshopje moeten maken voor school, is ook neit volledig afgewerkt en perfect in orde, maar mss krijg je er wat inspiratie door...
(relaties staan niet aangeduid)

db_schema.pdf

[Eriksk]

@Keneo: Voor welke opleiding was dit?

Eerlijk gezegd roept dit meer vragen op, dan dat dit inspiratie kan geven. Ik denk dat de discussie de we hier al gevoerd hebben meer input levert dan het db schema van jou webshop.

Wat is BongoOrder? Waarom zijn je id velden default null?

[Keneo]

Sorry, ik had niet zoveel tijd om alles uit te leggen op het moment van posten.

Dit was voor het vakoverschrijvend project in de 3e bachelor informatica @universiteit gent.

We hebben een webshop gemaakt in java icm struts en hibernate (draaidend op een tomcat server)..
(resultaat is nog te bezichtigen op http://bongo.ugent.be/bongo)
Design is van een externe designer van de kunstacademie en niet geoptimalisseerd voor IE, dus daar niet over klagen

Bongo was de codenaam voor onze webshop, en order was een niet toegestane naam in hibernate, vandaar bongoOrder.

De structuur is zo:
tabel users (evident) pw encrypted met een apparte salt per user en het id van zijn huidige basket (kan ook omgekeerd, basket die userid bijhoud) en net zoals bij u 2 'booleans' enabled en isadmin.

Verder een basket die bestaat uit een lijst van basket_lines
dus per item in het basket een itemid en itemcount (available en subtotal mogen daar eigenlijk niet bijstaan, dit zijn berekende velden, maar hibernate zet ze er toch bij, deze worden nooit gebruikt)

In de basket wordt dus nog de actuele prijs van een item gebruikt.
Eens de user naar checkout gaat wordt de basket omgezet in een echt order, dat dan op zich weer bestaat uit orderlines, die deze keer wel de actuele prijs bijhouden. (btw zou hier ook bijkunnen, maar we hadden gekoezen om alle prijzen incl. btw in de db te stoppen en btw % informatief op te slaan, nooit mee rekenen, aangezien er nooit facturen opgesteld worden)

Een item bestaat uit een titel, prijs, btw percentage, image(url), datum van toevoeging, evt promoprice (om aan te geven: vroeger €20, nu €15) en een category.

Een categorie kan dan gebruikt worden om extra velden aan het item toe te voegen.
Zo zal de categorie CD de properties: titel, artiest, label... bevatten.
De category T-shirt zal dan de property maat hebben en evt related artiest...

Een category bestaat dus uit propertie-definities, een property zelf bestaat uit een propertydefinition en de bijhorende value, elk item heeft dan afhaneklijk van zijn categorie een lijst met properties (dit is de tabel Item Property)

Properties zullen ook een rank krijgen om te beslissen welke propertie bvb boven een artikel getoond moet worden in het algemeen overzicht, en welkeen slechts detail is...

Verder zijn er ook voorzieningen voor een NewsletterArchief, persistent login (mbv coockies) op meerde plaatsen...

De database structuur is volledig automatisch gegenereerd door hibernate, gebasseerd op onze Entity classes in java...

Verder zou ik hibernate/struts afraden, en JAVA EE gebruiken in de toekomst

Hopelijk is dit al iets duidelijker...