--- title: "flera egenskaper (e-handel)" type: "forum-thread" url: "https://www.webforum.nu/amne/asp/94965-flera-egenskaper-e-handel" topic: "ASP" topic_url: "https://www.webforum.nu/amne/asp" author: "Gimbo" published: "2004-01-15T21:29:46.000Z" updated: "2004-01-20T17:15:14.000Z" replies: 24 views: 768 page: 1 pages: 2 language: "sv-SE" site: "webForum — webforum.nu" rights: "Upphovsrätten till varje inlägg tillhör dess författare." attribution: "Citera som: webForum, https://www.webforum.nu/amne/asp/94965-flera-egenskaper-e-handel" --- # flera egenskaper (e-handel) _Sida 1 av 2._ ## #1 — Gimbo, 2004-01-15T21:29Z hejsan, har verkligen ett problem här... det är så här att jag håller på o bygger en e-handelsplats, och låt oss säga att jag säljer skor, man klickar på en viss sko, då syker den upp i en pop up, sedan finns d en drop down med olika storlekar på dojjan, de väljer en storlek och klickar på add to cart, popupen försvinner och dojjan läggs i kundvagnen. Nu till problemet, låt oss säga att de vill handla vidare ett par andra dojjer, samma process de väljer storlek och klickar på add to cart. hur fungerar det nu? dvs hur ska systemet veta vilken storlek som tillhör vilken dojja? vilken är den smidigaste lösningen till detta problem?? att loopa fram en massa storlekar från en databastabell, lr ange storlekarna i html och köra med session?? alltså har verkligen fastnat, skulle va tacksam med en spark i häcken, lite kod skulle inte skada. Permalänk: https://www.webforum.nu/p/94965 ## #2 — Jymdis, 2004-01-15T23:28Z 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. Permalänk: https://www.webforum.nu/p/1253082 ## #3 — tstone, 2004-01-16T10:19Z 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å men köp inget på skoj...[www.lane4.se](http://www.lane4.se) Permalänk: https://www.webforum.nu/p/1253213 ## #4 — OveRRidE, 2004-01-16T11:12Z 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). Permalänk: https://www.webforum.nu/p/1253249 ## #5 — OveRRidE, 2004-01-16T11:18Z 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. Permalänk: https://www.webforum.nu/p/1253253 ## #6 — Gladh, 2004-01-16T12:54Z 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 Permalänk: https://www.webforum.nu/p/1253316 ## #7 — OveRRidE, 2004-01-16T14:57Z 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? Permalänk: https://www.webforum.nu/p/1253384 ## #8 — Gladh, 2004-01-16T22:12Z 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 Permalänk: https://www.webforum.nu/p/1253615 ## #9 — OveRRidE, 2004-01-17T16:38Z 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. Permalänk: https://www.webforum.nu/p/1253881 ## #10 — Gimbo, 2004-01-18T14:55Z 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 Permalänk: https://www.webforum.nu/p/1254268 ## #11 — OveRRidE, 2004-01-19T07:34Z > 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? Permalänk: https://www.webforum.nu/p/1254537 ## #12 — Gladh, 2004-01-19T07:35Z 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 Permalänk: https://www.webforum.nu/p/1254538 ## #13 — OveRRidE, 2004-01-19T07:51Z En Accessdatabas däremot kan bli en *aning* stressad. ;) Permalänk: https://www.webforum.nu/p/1254546 ## #14 — Gladh, 2004-01-19T10:05Z > 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 Permalänk: https://www.webforum.nu/p/1254596 ## #15 — OveRRidE, 2004-01-19T10:12Z > **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. Permalänk: https://www.webforum.nu/p/1254600 ## #16 — Gladh, 2004-01-19T11:15Z > 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 Permalänk: https://www.webforum.nu/p/1254622 ## #17 — Gimbo, 2004-01-19T19:13Z 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 Permalänk: https://www.webforum.nu/p/1254907 ## #18 — Jymdis, 2004-01-19T20:43Z 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) Permalänk: https://www.webforum.nu/p/1254963 ## #19 — Gladh, 2004-01-19T21:08Z > 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 Permalänk: https://www.webforum.nu/p/1254978 ## #20 — Gladh, 2004-01-19T21:09Z > ä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 Permalänk: https://www.webforum.nu/p/1254981 --- Tråden på webben: https://www.webforum.nu/amne/asp/94965-flera-egenskaper-e-handel Nästa sida: https://www.webforum.nu/amne/asp/94965-flera-egenskaper-e-handel/page2.md