[SpaceDump]

Ursprungligen postat av allstars

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

[sca]

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?

[Lucas Welander]

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

[glennj]

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å.

[macwiz]

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

[mephisto73]

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.

[Conny Westh]

Ursprungligen postat av macwiz

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

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

[sca]

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?

[sca]

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?

[Conny Westh]

Ursprungligen postat av mephisto73

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 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....