Databasen för webbshop
 

Hej!

Jag håller på att konstruera en webshop.
Hur ska man göra med databasen som hanterar ordrar?
Det jag inte riktigt förstår är hur jag ska göra med tabellen "order". Antalet db-fält i tabellen kan ju inte vara statisk då en köper kanske 2 varor, medans den andra kanske köper 22 varor.

Hur ska man lösa det?

Du måste ha en tabell som innehåller dina produkter där alla har sitt egna produktId och sedan en tabell som heter kund, och order har 3 fält, orderid, kundid och produktid.
orderid är index i Order tabellen, och för varje produkt en kund köper så läggs det till en rad i databasen.

Exempel
Alltså, för varje produkt jag köper, säg att jag har kundid 1 och nisse har
kundid 2, jag köper produkterna med id 2, 3 och 4 nisse köper endast
produkterna 2 och 4, då kommer raderna se ut såhär:

Du kan också tänka i formen orderhuvud och orderrader.

Båda, tack för era svar, det hjälper mig en bra bit på väg.

En kompletteringsfråga...

Lucas, med ditt exempel så har varje specifikt exempel ett order-id. Varje beställd produkt är en ny order.
Är det vanligt att det ser ut så, eller är det vanligare att man samlar alla produkter till en order, som får ett order-id? Det jag funderar på är hur man presenterar det smidigast mot kund, och admin. Säg att tio kunder köper tre saker var, så känns det mycket att visa 30 ordrar när det i själva verket är 10... Är jag ute och cyklar eller har du någon lösning på det också?

DigiArt. Jag hänger nog inte riktigt med på vad du menar. Jag hoppas att du har tid och lust att förklara för mig lite närmre:)

När jag knappat webshop så har jag gjort en databaslayout ungefär som på nedan URL:

http://files.spacedump.se/webshopdb.png

Jag tycker det blir ganska smidigt så.
Den bör även förklara sig ganska bra själv hoppas jag. :)

//Anders

Nej du har såklart rätt där. jag som skrev lite galet, det du säger stämmer helt klart, i mitt fall kan man se det som att person1 har köpt 3 saker 3 olika gånger, dvs då blir det såklart 3 olika ordrar och person2 har köpt 2 saker 2 ggr, visserligen på samma dag men kanske inte på samma gång.

Men i stora drag, det som ska öka på antalet rader i order tabellen är antalet produkter.

njae, det ser bra ut men du måste göra en relation mellan kund och köpa produkter, så du kan generera ett kvitto eller faktura genom databasuppgifterna.

Så med andra ord saknar du orderraderid på tbl_order. du kan använda tbl_orderrader.id till tbl_order.orderraderid eller liknande men du måste ändå ha ett id fält som är primary key på tbl_order för att fortfarande kunna sortera alla ordrar och kunna plocka ut första 100 beställningarna etc.

så jag hade satt dit orderraderid som refererar till tbl_orderrader.id

Det har du väldigt rätt i, jag var nog lite väl morgonseg när jag slängde ihop den där imorse.. :)
Den är numer korrigerad.

//Anders

Lite för simpelt där. Om man ändrar pris på en produkt så ändras det i orderhistoriken vilket det inte bör göra.

Så en orderProduktTable bör finnas med pris (kan också förekomma rabatter) samt antal.

i produkter bör du ha fält för moms-sats eller en relation till en momstabell.
Priset ska gärna vara exkl moms.
För din egen skull kan det vara bra att ha en kolumn för inköpspris så du kan räkna förtjänst.

Ovan är bara ett snabbt exempel för att få in sca på ett spår. :)
Men ja, helt klart skall dessa även vara med.

//Anders

Tack för alla svar! Det värmer något enormt, att få den hjälp man behöver, när man behöver den.

Däremot så hänger mitt problem kvar i luften. Just databasen för produkter börjar bli lite enorm nu med alla rader som kan tänkas finnas i med länkar till bilder, produktinformation, moms etc. Men jag har inte lyckats lösa problemet med order-tabellen hur man i den lyckas få in alla de produkter som beställs och hur man kan få de under ett och samma order-id.

Är det något jag missat när jag läst alla inlägg flera gånger om?

Jag tycker du ska ta och rita upp hur din databas struktur ser ut i dagsläget, men mycket av detta hänger ju också på dina SQL frågor och om inte det räcker med bara SQL så kanske en foreach() sats kan hjälpa dig.

Tror nog det blir enklast för alla att förstå varandra om vi har något konkret att kika på som du försöker få att fungera och inte påhittade tabeller med enklaste möjliga struktur

Så här gör man i många system:

Tabell Orders:
Ordernr, Kundnr, kundinfo, orderdatum, etc etc
Ngn smart sa tidigare "tänk orderhuvud"

Tabell Orderrader
ID(Unikt för tabellen), Ordernr, Artikelnr,Artikeltext, Antal, Pris, osv osv)

SELECT * FROM Orderrader WHERE Ordernr=1 ger dig en lista på alla produkter
som tillhör en specifik order (I detta fall Ordernr 1).

Du kommer i princip aldrig göra Selects ur Orderrader tabellen utan att specifiera ett Ordernr, förutom om du kör ut statistik.

Tänk på att det är bra att göra raderna statiska, så att t.e.x Artikel eller produktnummer INTE relaterar direkt mot en produktdatabas, då får du problem som tidigare nämts om pris ändras osv. Personligen tycker jag inte att några relationer hör hemma här alls, men det finns många som tycker tvärt om också.

Ta en titt på db-schemat för osCommerce, där kan du säkert hämta lite idéer, http://www.oscommerce.com/community/contributions,3853

Jag vill inte låta för besserwissig men en webshop är nog ett väl tufft första projekt, och i alla fall jag skulle nog rekommendera att du kodar ett par enklare projekt innan du ger dig på en webshop.

Du bör ha en ganska bra koll på relationsdatabaser innan du tar dig an ett sådant projekt.

Ett par tumregler (mina hemmaformulerade) vad gäller databasdesign är

- se en tabellrad med fält som en definition av en enhet och dess egenskaper, varje rad blir sedan en instans av enheten
- undvik att dubblera data i möjlligaste mån.
- dela upp aspekter i tabeller, d.v.s. bilder är en aspekt av produkt, men lämpar sig bäst som en separat tabell (du kanske vill ha flera bilder per produkt i framtiden, och då är det bra att inte hårdkoda antalet i db-strukturen).

Dock så är just order och orderrader ett litet undantag eftersom syftet med dem är ett annat. De behöver fungera som ett kvitto som visar vad kunder beställt, och det måste vara statiskt, d.v.s. det får inte ändras i framtiden även om du ändrar pris och produktnamn.

Kundvagnen kan däremot vara en "dynamisk tabell".

Sedan behöver du även tabeller för betalningar/transaktioner , leveransadress, returhantering osv.

Det här inlägget funkar bättre: http://addons.oscommerce.com/info/3853

Tack alla vänliga själar!

Jag skall definitivt kolla schemat för osCommerce (och installera det på min server för att studera detta).

mephisto: Det är inte mitt första projekt, då jag har jobbat ganska mycket med php och gjort diverse lösningar och villa ha en utmaning :) Därav gick jag på arbetet med att konstruera en webshop:)

Lucas: Finns det något särskilt program man kan använda i datorn för att rita upp databasstrukturen? Det kan ju vara bra att ha för detta och framtida projekt, men jag har inte hittat något än.

GlennJ: Myckewt är väl en smaksak, men jag känner nog precis som du med att var sak på sin plats och att inte blanda ihop för mycket. Min erfarenhet säger att ju mer du blandar ihop, desto lättare för en massa buggar etc. Men jag kanske har fel där, vem vet?
----
För övrigt så använder jag codeigniter. Jag känner mig bekväm med det ramverket, men om det är lämpligt för detta ändamålet? - Det tror jag. Dels så har det ett hjälpmedel för just kundvagnen som jag hoppas kan ha nytta av samt en massa övriga hjälpmedel också för den delen... men vi får se. Har mycket att prova nu efter alla era inlägg.

Om man jämför med övriga shopp-moduler som t.ex. textalk m.m. där en kund abonnerar på en webshop och inte äger den själv....Skiljer sig dessa system jämfört med liknande system för konkurrenter och vad är det som är bra med vissa webshoppar respektive mindre bra, så man inte gör lösningar som helt saknar kundvärde och som för övrigt innebär att man lägger ner tid på något ingen vill ha?

Kom också att fundera på en sak. osCommerce... Är inte det ganska segdraget med uppdateringar? Var inte senaste uppdateringen för typ 5-7 år sedan. Vad jag fattat det som används det trots detta rätt flitigt...Klarna har gjort en separat betalningsmodul (andra betalningsaktörer också för den delen). Vad tycker ni om det systemet och dess brist på uppdateringar?

Det finns massor av tabeller man måste tänka på, det är exempelvis Faktura/Fakturarad, det är inte samma sak som Order/Orderrad. Order behöver man inet spara för bokföringen, men faktura måste man spara för bokföringen.

Order och faktura är inte heller mappade 1:1 utan det kan finnas en order som genererar flera fakturor, beroende på att ordern var stor och inte kunde levereras samtidigt, men man vill som leverantör fakturera så fort man levererat. Då kan en order bli flera fakturor.

Sen finns det samfakturering dår man slår ihop flera små ordrar till en faktura.

Vi kan ta objektet Adress som är ett eget objekt i många sammanhang. I en faktura kan man behöva ange flera adresser, exempelvis Beställaren, Särskild leveransadress, och det finns även betalare som kan vara ett factoringbolag, då är vi uppei tre olika adresser, som är mycket vanligt.

Det kan även vara så att en kund delbetalar en faktura, pga av likviditetsbrist, då måste man kunna hantera alla betalningar för sig. En betalning mappar inte direkt 1:1 mot en faktura utan det kan vara flera betalningar på en faktura. Det kan även hända att en betalning avser flera fakturor, det måste man ta hänsyn till i databasen om man ska kunna hålla koll på kundreskontran eller leverantörsreskontran för den delen också.

Det finns ju även offert/offertrad.

Man ska skilja på produkt och pris då priset bör hanteras i en Prislista. En prislista består av många prislisterad. Varje prisrad ska ange priset för en produkt. Prislistan i sig har en viss giltighetstid från-/tilldatum. Varje kund kan ha ett eller flera Avtal och varje avtal har en koppling till en specifik prislista.

Som sagt så finns det massor av aspekter man måste tänka p åvid datamodellering. Men man måste börja ett par steg tidigare och skriva ner kraven som verkamheten ställer på systemet, sen ska man göra en knceptuell modell, dvs en mycket grov skiss över vilka verksamhetsobjekt som är involverade, man msåte ha koll på vilka användarroller som systemet ska betjäna (Exempelvis Webbkund och en administratör är exempel på två olika roller med olika behörighet i systemet.)

and on and on and on....

När man modellerar en databas så ska man se till att alla värden är atomära, dvs odelbara i sin grundform, dvs man skriver tiltalsnamn för sig och efternamn för sig, postnr för sig och postort får även det en egen kolumn.

Värsta skräckexemplen jag sett är när man lagt ihop förnamn, efternamn, gatuadress, postnr, ort, land i samma kolumn..... hjärnsläpp, hur ska man då hantera ett urval på kunder som har ett visst postnr eller bor på en speciell ort?


Viktigt att man döper alla kolumner till unika namn för annars kan man få problem vid joinar av flera olika tabeller. Man kan slarva lite här med främmande nycklar, men det får man leva med.

När man döper en tabell ska man döpa den i singularis exempelvis tabellen Order och Orderrad, plural använder man i de transienta listorna Exempelvis i C# skulle man kunna deklarera (om vi kör med engelska i koden).

Om man har en räknare som Primärnyckel i Order-tabellen så bör den heta orderID eller orderNr och inte enbart id, eftersom id då kommer att komma i namnkonflikt med id i Faktura-tabelen om man gör en join mellan dem. Visserlign kan man använda ett alias på kolumnen vid en join men man ska ha som princip att alltid försöka skapa så stabila datastrukturer som möjligt i databasen för den kommer leva under många år och det kommer troligen att byggas många stödsystem runt, denna databas, då vill man ha konsekvent namnsättning och tydlighet och definitivt inga namnkonflikter.

Använd naturliga primärnycklar om det finns, det underlättar enormt om man kan få en koppling till en extern datakälla med uppdateringar. För att ta ett enkelt exempel så är postnummer en extern datakälla då det är typ posten som uppdaterar dem. Då är det ju smidigt om man kan få en uppdateringa av dem och med ett enklt SQL-script kan uppdatera hela min databas genom att koppla ihop mina kunders adresser med ett enkelt postnummer.

ConnyWesth: Jag tackar så enormt mycket för din Feedback. Den kommer hjälpa mig och säkert många andra som befinner sig i likvärdig situation som jag. Infon är guld värd.

Om jag tänker så här när det gäller momentet order:

order_tbl -> Ska innehålla grundläggande information och tilldela ordern ett ordernummer.
För att detta ska vara möjligt har jag funderat ut en lösning likt rutinen:

Ett PHP-script tar infon från vem som handlar och skjuter i denna infon (adresser och övriga kunduppgifter) i order_tbl och vi får då även ett order_id (som är satt till primary key på auto-update).
När PHP-scriptet fortsätter att exekveras tar den ut order_id't från order_tbl och placerar detta numret tillsammans med alla de produkterna som kunden har beställt vid detta tillfälle.

Är det en bra lösning?

Samtidigt undrar jag hur man kan göra för att motverka att om två kunder beställer vid samma tidpunkt så att de inte får upp den andras beställning på grund av extremt minimalt tidsspann. Så här tänker jag:

Kund 1 lägger en beställning 23:50:00
Kund 2 lägger en beställning 23:50:01

Det jag tänker på är att när scripten körs så blir det ett visst spann och säg att kund två lägger sin beställning precis innan scriptet för kund 1 ska hämta order_id't kan det ju bli så att den hämtar kund 2's order id. (Om scriptet väljer att hämta det senaste order-id't i tabellen.) Teoretiskt är det ju en risk, men hur stor är chansen att detta händer om man gör så eller finns det ett annat tillvägagångssätt?

Jag hoppas ni hänger med på vad jag menar.

Ett gott råd till sca är att läsa på ordentligt om databasdesign eftersom inläggen anger att det är mycket kvar att lära där ;)