flera egenskaper (e-handel)

Du kör väl in varje objekt en kud beställer i en cart databas med en id till vilken kund det är, samt storlek, färg och all annan information som kan tänkas. Allra enklast är det ju om du har en unik id för varje storlek, färg osv av varje sko du har, så slipper du ha så många fält i cart databasen.

Använder du någon editor typ dww mx eller motsvarande? Ofta är kundvagnen någon form av temporär tabell som lagras efterhand som köpet bekräftas. I de varianter jag arbetat med lagras varorna som cookies fram tills det att köpet går igenom och först då lagras ordern i databasen.

:D Återkom gärna med mer info

Kolla gärna på https://www.lane4.se men köp inget på skoj...www.lane4.se

Hrm. Funderat på en relationstabell för storlekar på skor? Jag skulle nog vilja säga att svaret på din fråga beror på hur systemet ser ut.

Har alla skor alltid samma val när det gäller storlek? Alltså; oavsett vilken sko du tittar på, har den alltid storlekarna 28-45 eller varierar det från sko till sko? (Antagligen varierar det, antar jag)

Jag skulle nog ha alla skomodeller i t.ex. tblShoe och sedan ha alla relationer till storlekarna för varje modell i tblShoeSize. Denna tabell i sin tur relaterar till tblSize som innehåller storlekarna.

Utdrag ut tblShoe
ShoeId | ShoeName
---------------------------
12 | Nike H4xx0R
13 | Puma n00b
14 | Puma L337

Utdrag ur tblShoeSize
SizeId | ShoeId
---------------------------
1 | 12
2 | 12
3 | 12
4 | 12
2 | 13
3 | 13
4 | 13

Utdrag ur tblSize
SizeId | SizeName
---------------------------
1 | 40
2 | 41
3 | 42
4 | 43
osv

Denna modell visar att skomodellen 'Nike H4xx0R' finns i storlekarna 40, 41, 42, 43, att 'Puma n00b' finns i tre storlekar; nämligen 41, 42 43 samt att modellen 'Puma L337' faktiskt inte finns i någon storlek alls (vilket kanske borde undvikas).

Jag skriver ett nytt inlägg istället för att redigera, det blir så långt. :)

Kanske skulle du till och med (om du vill utöka sortimentet från skor, till t.ex. andra produkter som inte beror på storlekar) kunna dlpa om tabellerna till tblProducts, tblProductProperties och tblProperties. Isåfall kan du ha precis vilka värden du vill på det som vi kallade storlekar innan, det är bara att döpa dem i tabellen tblProperties, t.ex. färg, antal i ett paket osv.

Jag brukar använda mig av följande struktur:

En tabell som heter tblOptionGroup som innehåller olika grupper av valmöjligheter, typ en som heter Färg, en som heter Storlek osv osv...

Denna tabell har dels ett internt namn och ett externt, eftersom många grupper blir snarlika. Så det kan se ut så här

tblOptionGroup
ID|IName____|EName|....
-----------------------------
01|FärgSkor__|Färg
02|FärgByxor_|Färg

Sedan har jag en tblOption som innehåller alla valmöjligheter.

tblOption
ID|Name|.....
-----------------------------
01|Röd
02|Grön
03|Gul

Sedan en tabell som kopplar ihop tblOptions med tblOptionsGroup, tblOptionGroup_Option

tblOptionGroup_Option
IDOptionGroup|IDOption|....
--------------------------------
01__________|01
01__________|02
02__________|01

Nu har jag 2 olika grouper som jag kan använda som Färg valmöjlighet.

Sedan har jag en tblArticle där artiklen ligger lagrad, och sedan en tblArticle_OptionGroup, så att man kan ha flera valmöjligheter till en article, typ färg och storlek.

tblArticle_OptionGroup
IDArticle|IDOptionGroup
---------------------------------------
01_____|01
01_____|02

Sedan måste varje Optionsval sparas ner i databasen så det matchar den article som man har köpt. Först lagras articlen i en tblOrderRow. Denna är kopplad med en tblOrderHeader (orkar inte visa den)

tblOrderRow
ID|IDArticle|Quantity|Price...
---------------------------------------
01|01____|1______|110.50
02|01____|3______|135.00

Till sist så har jag en tblOrderRow_Option som kopplar ihop en orderrad med de valmöjligheter som man har valt på artiklen

tblOrderRow_Option
IDOrderRow|IDOption
---------------------------------
01________|01
01________|02
02________|01

Det blir några tabeller, men ett total flexibelt system, du kan lägga till hur många valmöjligheter som helst, till hur många grupper, du kan sedan koppla hur många grupper du vill till en artikel och alla dina val kommer att sparas tillsammans med din orderinformation för just den artiklen. Mycket bättre blir det inte :)

Du kan sedan bygga ut dina tabeller, så man kan ha olika priser för olika valmöjligheter. Säg att färgen svart kostar 50 kr extra. inga problem, lägg till kolumnen Price i tblOption och i tabellen tblOrderRow_Option. Och du kan ta med den kostnad när du räknar ut total priset på produkten.

Sedan gör jag så att när en kund väljer att lägga till en vara i korgen så skrivs den direkt ner till tblOrderRow. Detta kräver att man kan koppla ihop just denna rad med kunden, samt även en lösning om kunden inte loggat in (då har man inget kundid :) ).

Sedan när kunden går till kassan, och skickar order, så läggs alla orderrows samman och en orderHeader rad skapas och läggs i tblOrderHeader.

Man kan ta bort alla "oköpta" varur i tblOrderRow om man vill, eller så använder man det som statistik, och gör analyser av köpbeteende och varför köpet inte genomfördes, osv osv...

- Magnus

Jag skulle nog föredra att ha två tabeller som sköter hanteringen radhanteringen av produkterna. En som heter något i stil med tblCartRow och en tblOrderRow, så att man kan spara och framförallt separera en färdig order från en ufullständig. Då får man dessutom kvar alla attribut, som t.ex. dina Options.

Såsom jag förstod det ville du summera allt på en rad, när ordern läggs? Tappar du inte alla knytningar till Options då, om man sen vill se ordern radvis igen och eventuellt göra ändringar?

Det finns ingen anledning att ha 2 tabeller för orderrader, eftersom dessa kan separeras på IDOrderHeader. Om en rad inte har denna post satt, är inte artiklen köpt. Tillsammans med ett datum fält kan man enkelt se om posten är inaktiv eller aktiv.

Alla orderrader och optioner finns kvar, men en speciell OrderHeader rad skapas, där man kan (om man vill) summera ihop summan för alla artiklar, samt antalet. I denna rad spara man också information som tidpunkt, kundid, betalningssätt, leveranssätt osv osv...

- magnus

Jo, men då var det så jag trodde, fast det inte verkade så innan, då jag antagligen missförstod. :OO ;)

Jag brukar dock separera orderrader från kundvagnsrader, men systemet som du säger med Orderheaders är rejält användbart och även så jag brukar göra.

sorry för att va en aning seg, va på semester...
det är så här att jag har en tabell som heter cartRows och där lagrar jag:

idProduct
quantity
price
idDbSessionCart

så ni menar att jag ska lägga ett till fält här som heter size och sedan ha en relation med en annan tabell?

men override blir det inte lite väl för många poster då jag exempelvis skall ha 20storlekar och kanske har 500 olika artiklar?? blir det inte 500*20 poster i tabellen shoeSize som du visa... för samtliga skor skall finnas i samtliga storlekar hela tiden

men override blir det inte lite väl för många poster då jag exempelvis skall ha 20storlekar och kanske har 500 olika artiklar?? blir det inte 500*20 poster i tabellen shoeSize som du visa... för samtliga skor skall finnas i samtliga storlekar hela tiden

Det beror på. Det finns alltså inga undantag när det gäller att alla skor skall ha samma storlekar, rakt över?

Om du använder min lösning så kommer du få följande rader. (utgår ifrån att alla skor har samma storlekar att välja på).

- I tabellen tblOptionGroup får du en rad som heter Size
- I tabellen tblOption får du 20 rader som beskriver de olika storlekarna samt använder sig av ID för size från tblOptionGroup
- I tabellen tblArticle_OptionGroup får du 500 rader, där du kopplar ihop varje artikel med OptinsGruppen Size

När sedan någon köper en sko, så får du 1 rad i tblOrderRow som beskriver artiklen som du köpt. Samt 1 rad i tblOrderRow_Option som beskriver vilken storlek som du har valt för just denna sko.

Ett mer flexibelt system har jag svårt att tänka mig att du får, det är dessutom enkelt att bygga ut, samt följer normaliseringsmodellen.

Bygger man bara sin databasmodell korrekt så behöver man aldrig vara rädd för att det blir många rader i en databas, jag har sysslat med MS SQL Server som har haft miljontals rader i en tabell, eftersom den är korrekt uppbygd och har rätt index, så tar det mindre än 1 sekund att få ut den data man vill ha.

En databas är byggd för hantera data, och det är den bra på. Men det kräver att man bygger sin databas korrekt, och inte hittar på egna konstiga lösningar, som att lagra kommaseparerade strängar i en post, för att visa vilka optioner som en artikel har. Helt förkastligt.

- M

En Accessdatabas däremot kan bli en aning stressad. ;)

En Accessdatabas däremot kan bli en aning stressad

Det stämmer, men vem använder en Access databas till en webbplats som kan få så mycket data i sig?

- M

Gladh skrev:

En Accessdatabas däremot kan bli en aning stressad

Det stämmer, men vem använder en Access databas till en webbplats som kan få så mycket data i sig?

- M

De som inte har råd att antingen skaffa en egen MSSQLServer-licens eller inte har råd att hyra.

De som inte har råd att antingen skaffa en egen MSSQLServer-licens eller inte har råd att hyra.

Då införskaffar man sig antingen MySQL eller MSDE, ingen av de kostar pengar (jmf med access) och båda är betydligt bättre :)

- Magnus

jag använder mig utav access nu :r detta enbart för att jag inte har råd med ms sql och att jag använder mig utav asp, mysql fungerar ju inte med asp, vad är MSDE för något fungerar det med asp? om ja, är det enkelt att konvertera en access databas till MSDE?

Gladh >> din tanke låter klockren, ska nog ta och sätta mig in i det tankesättet får se hur långt jag kommer, va beredd på att jag kommer skrika om hjälp :p

mysql fungerar visst det med asp?
msde är en skrivbordsversion av ms sql server, men den är enbart för utveckling så den skulle jag inte rekommendera (den har samma begränsningar som pro versionerna av IIS, dvs den klarar bara ett visst antal anslutningar)

den har samma begränsningar som pro versionerna av IIS, dvs den klarar bara ett visst antal anslutningar

Det stämmer faktiskt inte, den klara hur många anslutningar som helst, begränsningen ligger i att om man har mer än 5 samtidiga exekveringar mot databasen så läggs en fördröjningsrutin på.

Ivilket fall som helst så har MSDE bättre prestanda än Access, samt att man kan använda sig av SP och triggers om man vill det. Sedan så är det enklare att uppgradera från MSDE till MS SQL Server än från Access till MS SQL Server.

Sedan är det inte IIS som har begränsningar på antalet anslutningar, utan OS:et isig. Även om det är allt för många som tror att begräsningen ligger i IIS:en.

- M

är det enkelt att konvertera en access databas till MSDE?

Det är enkelt att konvertera från Access till MS SQL Server, men det beror inte på databasen utan på de klient verktyg som följer med. Tyvärr följer inte dessa med till MSDE.

- M