25 svar · 1 034 visningar · startad av trexter.com
Efter att ha läst nästan allt i forumet som har att göra med
webshopar och handelssystem så har jag börjat fundera lite på
hur jag själv vill ha det.
Jag hade tänkt mig att lagra kundkorgarna cookies. Det ska
spara en del serverkraft vad jag förstått, nackdelen är tydligen
att det helt enkelt är besvärligt...
Sedan måste man ju kunna koppla de olika kundkorgarna till de
olika besökarna. Men blir inte det "automatiskt" när man
använder cookies eller har jag missat någonting? Jag menar att i
och med att varje användare har en unik cookie på sin hd så vet
man vilka varor de beställt.
Jag hade tänkt mig en tabellkostruktion som jag hittade efter en
sökning här på Wf:
PRODUKTKATEGORIER
PRODUKTER
KUNDER
VARUKORG
Det kommer alltså bli som så:
Besökaren går in på sidan > Väljer kategori > Väljer varor >
Sparas i en Cookie > När beställningen sker övergår infon från
cookie till databas. > Klart!
Men hur fixar man så att en och samma person kan beställa flera
varor? Här är jag bara som ett enda stort frågetecken. Hur
brukar man göra? Det vore trevligt om man fick lite "exempelkod"
på databasstruktur och cookiestruktur.
Jag vet att sådana här relationer är lättare att ha o göra med i
XML men måste jag verkligen dra in det (som jag inte kan)?
Sedan undrar jag om det är någonting mer som skiljer
"Access-programmering" och "MYSQL-programmering" än att de
har lite olika kopplingar och att man inte använder RecSet med MYSQL?
Jag hade nämligen, i så fall, tänkt att man kommenterar
bort "MYSQL-kod" med '. Vill någon använda den databasen får
dem helt enkelt kommentera bort Access istället. Låter det
vettigt?
:)
.. Det ska spara en del serverkraft ..
Behöver du spara serverkraft?
Just proceduren databas->cookie->databas, känns den naturlig?
Som du antyder så är modelleringen av databasen det viktigaste. Rätta relationer, referensintegritet osv.
Själva systemeringen och dataflödet är det viktigaste. börja skissa på det. Var och hur varukorgen ska fungera är ett mindre delproblem.
Tack för svaret!
Toonster skrev:
Behöver du spara serverkraft?
Behöver och behöver. Systemet kommer antagligen oftast köras
med en Access-databas så då är det väl alltid bra att försöka spara så mycket serverkraft som möjligt?
Toonster skrev:
Just proceduren databas->cookie->databas, känns den naturlig?
Finns det några nackdelar med den om jag bara får det att
fungera? (Förutom att somliga har cookies avstängda.)
Toonster skrev:
Som du antyder så är modelleringen av databasen det viktigaste.
Rätta relationer, referensintegritet osv.Själva systemeringen och dataflödet är det viktigaste. börja
skissa på det. Var och hur varukorgen ska fungera är ett mindre
delproblem.
Ja, själva grunden är så klart viktigast man jag måste väl ändå
redan nu veta hur jag ska gå tillväga med problemet om samma
person beställer flera olika saker? Det är ju beroende på svaret
jag får på den frågan som jag kommer designa systemet. Eller
tänker jag fel?
Vad är referensintegritet för någonting?
:)
Du kan ju förslagsvis ladda hem en färdig E-Shop, för att få svar på alla dina små problem..
http://www.hotscripts.com/ASP/Scripts_and_Components/ - där förslagsvis..
alj skrev:
Du kan ju förslagsvis ladda hem en färdig E-Shop, för att få svar på alla dina små problem..
http://www.hotscripts.com/ASP/Scripts_and_Components/ - där förslagsvis..
Det ska jag göra! Under tiden väntar jag på fler svar!
:)
läs lite om arrays så kan du nog lösa det ;)
när du sparar produkterna i cookien så separerar du dem mex ex ";"
sedan för att ta ut produkt för produkt i cookien så splittar du den:
strProdukt = Split(strCookie, ";")
Nu får du fram alla produkter som finns med:
strProdukt(0), strProdukt(1), osv..
men som sagt läs mer om arrays så löser det sig nog :)
Poffe >>> Det kan jag och det ger hjälper mig inte!
Hur hade du tänkt att det skulle se ut i db:n då någon beställt
flera saker?
Antingen får man ha köpare och produkter i olika tabeller (det är
kanske så jag borde göra?), eller får man ha rader som är delvis
tomma alt. använda XML istället (vilket jag helst inte vill)...
:)
Köpare och produkter ska helt klart sparas i separata tabeller.
Gör som Poffe föreslår. Spara i en cookie och avsklij med semikolon (;). Splitta upp det och hämta sedan vidare information om produkten från databasen med t.ex.:
strSQL = "SELECT productPrice, strProdName FROM tblProducts WHERE id = "& strProdukt(0)
Då kommer det alltså bli någonting liknande (mycket förenklat):
Tabell 1 (Information om köpare):
-ID- -Namn-
1-----Nisse
2-----Bosse
och
Tabell 2 (Beställningar):
-ID- -Produktnr- -Antal- -Kostnad-Datum
1-----34-----------20-------56743
1-----15-----------4---------32452
2-----14-----------67--------345
Tabell 3 (Produkttabell):
-ID- -Kostnad-
34-----45634------
14-----3456------
15-----34555-------
Ser det någorlunda vettigt ut?
Och är det jättedumt att lagra kundkorgarna i cookies?
:)
Ekström skrev:
Köpare och produkter ska helt klart sparas i separata tabeller.
Med produkter menar jag egentligen (skrev fel) varubeställningar men jag antar att du ändå skrivit samma svar... ?
:)
trexter.com skrev:
Med produkter menar jag egentligen (skrev fel) varubeställningar men jag antar att du ändå skrivit samma svar... ?
:)
Det kan du lita på. :)
Tabell 3 är varubeställningar, va? Isf behöver du ett fält som refererar till kundens id. I stället för att lagra priset ska du lagra produktens specifika ID och därefter plocka ut pris på din ASP-sida. I annat fall så ligger ju samma pris kvar även fast du ändrar det.
Tabell tre borde innehålla dessa fält
id (primärnyckel)
kund - fält som refererar till en kund
datum - datum då kunden beställde.
prods - fält som refererar till samtliga produkter kunden har köpt. Skilj dem åt med ett semikolon. Särskilj antal av produkten med komma.
Fältet prods kan alltså se ut såhär:
12321,1;84730,5;324234,2; osv då siffran/siffrorna efter kommat är antalet produkter.
Hmm... det råkade faktiskt vara så att tredje tabellen var produkttabellen! :r Jag ska lägga till namnen i inlägget så att alla vet. Under tiden kanske du kan skriva om ditt inlägg efter dem nya omständigheterna så vore det toppen!
:)
prods - fält som refererar till samtliga produkter kunden har köpt. Skilj dem åt med ett semikolon. Särskilj antal av produkten med komma.
Fältet prods kan alltså se ut såhär:
12321,1;84730,5;324234,2; osv då siffran/siffrorna efter kommat är antalet produkter.
Hoppla! :o
Tyvärr är detta ansett som dålig databasdesign, då "databaser i databaser" inte är något förmånligt alternativ vid en eventuell ändring av den data som är sparad i denna kolumn. Jag vill inte ens fundera på varför man skall lägga tid på att skriva en avancerad funktion som spårar reda på en viss produkt genom att söka igenom en textsträng, och sedan skriva ett mönster som hämtar datat, för att slutligen knåpa ihop sträng-skrället igen. För att inte tala om att ändra antalet produkter. ;)
Nej. Skapa en relationstabell istället som innehåller en rad för varje produkt som kunden köper, som lagrar kundId och produktId. Jag brukar faktiskt även ha med pris i denna kolumn för att kunna komma ihåg kundens eventuella rabatt (som vanligtvis skapas direkt i presentationslagret och inte vid själva beställningen). Antal kan väljas att lagras i denna tabell, jag väljer dock oftast att inte göra det, jag anser det bättre att lägga så många rader som kunde beställer antal av produkten.
Då var jag själv inte så långt ifrån den bästa databasdesignen, eller?
Sedan förstår jag inte det som Ekström ;) sa att kundens kostnadsbelopp skulle kalkuleras dram genom att man gick från ID in i varuregistret och på så sätt fick fram en summa istället för att redan ha en kolumm med priset...
Beställer någon en kaffekokare på Måndag för 200:- och jag sedan höjer till 300:- på Tisdag ska han ju inte behöva betala en hundralapp extra...
:)
Beställer någon en kaffekokare på Måndag för 200:- och jag sedan höjer till 300:- på Tisdag ska han ju inte behöva betala en hundralapp extra...
Om det var mig du svarade på så får du läsa igenom mitt inlägg igen, för det var så jag menade och även så jag skrev.
Nu vet jag alltså på ett ungefär hur jag ska bygga upp databasen. kundkorgstabellen kommer t.ex. se ut så här:
Datum
Kostnad
Antal
ProduktID (kopplat till annan tabell så att man får reda på vad som köpts)
PersonID (kopplat till annan tabell så att man får reda på vem som köpt)
(Färg)
Då måste cookien byggas upp så här: Eller hur?
Produkt
Antal
Färg
:)
Så det blir en kundkorg i en databas i varje fall... Det är ju på snudd till idiotiskt att spara beställningarna både i cookies och i en databas ;)
Toonster skrev:
Så det blir en kundkorg i en databas i varje fall... Det är ju på snudd till idiotiskt att spara beställningarna både i cookies och i en databas ;)
Du kan ha rätt, du kan ha fel...
Varför är det idiotiskt?
Uppväger inte "serverkraftssparandet"
det extra arbetet eller hur menar du?
Är detta med cookies som kundkorg en vanlig lösning?
:)
Egentligen anser jag att vissas jagande efter serverkraft och prestanda ibland når löjliga höjder. ;)
* Lagra kundkorgen på servern, men se till att skilja den från ordertabellen
* Om du vill spara prestanda:
+ Använd option explicit
+ dim:a alla variablar
+ optimera din kod och använd OLEDB, getRows, osv.
Jag tror jag kör på mina kakor vare sig det är dumt eller ej! :p
Men hur kommer jag runt följande problem:
Om man beställer många olika slags varor så blir det en himlans massa cookies:
Response.Cookies("1")("ProduktID")="34"
Response.Cookies("1")("Antal")="4"
Response.Cookies("1")("Farg")="0"
Response.Cookies("2")("ProduktID")="45"
Response.Cookies("2")("Antal")="3"
Response.Cookies("2")("Farg")="0"
Response.Cookies("3")("ProduktID")="12"
Response.Cookies("3")("Antal")="4"
Response.Cookies("3")("Farg")="0"
Kan man fixa detta på något smart sätt?
Sedan vill jag förstås att Cookiesarnas namn ska vara unika. Hur fixar jag det?
:)