Jump to content
php.lv forumi

par e-veikalu preču groziņu


lame

Recommended Posts

Tātad ir jautājums par e-veikalu preču groza realizāciju.

Kā to vislabāk izdarīt?

 

Pašam ir iešavušies prātā 2 varianti(būtiski, ka lietotājs nelogojas iekšā sistēmā):

1.) Lietotāja izvēlētās preces ID un daudzums tiek glabāts sesijā, un pie vajadzības pēc preču ID noselektē preces un attēlo groza saturu.

2.) Datu bāzē izveido tabulā jaunu grozu ar kādu ID(šo ID saglabā sesijā), kurā arī sakrāmē preces. Saprotu, ka šis gadījums vairāk noslogos datu bāzi, un vēl būs jārūpējas par piepildītiem groziem, kas nav nopirkti.

 

Kādi būtu jūsu ieteikumi?

Varbūt kaut ko esmu sadomājis galīgi aplami?

Link to comment
Share on other sites

1ais. Pēc apstiprināšanas - tabulā atskaitēm.

18990[/snapback]

 

a vot nē... ja baigais šops, tad groziņš jātur tabulā.. pats esmu šādu groziņu lietotājs un ļoti ērti - saveido groziņu, un tikai pēc dažām dienām pasūti...

 

+ nepazūd infa pēc sessijas nobrukšanas (browser close/pc restarts)

+ iespēja norēķināties vēlāk

Link to comment
Share on other sites

mazam katalogam pirmais. bet ja liels veikals un gribi userim nakosajaa reizee `iemest aciis` to ko sis iepriekseejaa reizee ielicis grozaa, vai pat radit ieprieksejo grozu, vai kaut kaadu atskaiti sev par to kuras preces saliktas grozaa un nav nopirktas - thipa wishliste tad otrais.

 

no taas infas kas dota imo konkreti neviens nepateiks kaa tieshi tavaa gadiijumaa labaak, es taisiitu pirmo variantu - vienkarsak un bez liekaam fiichaam :)

Link to comment
Share on other sites

es reku skatījos uz šo te:

būtiski, ka lietotājs nelogojas iekšā sistēmā

t.i. ja pēc Delfina ieteikuma glabāt tabulās un atrādīt citā reizē, ļoti iespējama situācija kad kādā publiskā vietā (whateva, dalīts IP) kādam svešam atrādīsies tavs groziņš. Un tas nu gan nav jauki un vismaz neētiski no pārdevēja puses.

Link to comment
Share on other sites

es reku skatījos uz šo te:

 

t.i. ja pēc Delfina ieteikuma glabāt tabulās un atrādīt citā reizē, ļoti iespējama situācija kad kādā publiskā vietā (whateva, dalīts IP) kādam svešam atrādīsies tavs groziņš. Un tas nu gan nav jauki un vismaz neētiski no pārdevēja puses.

18993[/snapback]

 

a šito palaidu garām... vainīgs. tad viennozīmīgi 1-ais variants

Link to comment
Share on other sites

Tātad ir jautājums par e-veikalu preču groza realizāciju.

Kā to vislabāk izdarīt?

 

Pašam ir iešavušies prātā 2 varianti(būtiski, ka lietotājs nelogojas iekšā sistēmā):

1.) Lietotāja izvēlētās preces ID un daudzums tiek glabāts sesijā, un pie vajadzības pēc preču ID noselektē preces un attēlo groza saturu.

2.) Datu bāzē izveido tabulā jaunu grozu ar kādu ID(šo ID saglabā sesijā), kurā arī sakrāmē preces. Saprotu, ka šis gadījums vairāk noslogos datu bāzi, un vēl būs jārūpējas par piepildītiem groziem, kas nav nopirkti.

 

Kādi būtu jūsu ieteikumi?

Varbūt kaut ko esmu sadomājis galīgi aplami?

18989[/snapback]

 

pirmais variants! Viennoziimiigi!

tipa tabula carts(sesijas_id,produkta_id,nopirktais_skaits,timestamp....)

Kad izdara pirkumu, sapuusham visu tabulaas

orders (prieksh infas par pasuutiitaaju (pasuutiitaaja rekviziiti, ip, laix...)) un order_details (ordera_id, produkta_id, cena_pirkshanas_briidii...)

 

otram variantam ir jeega tikai tad, ja ir regjistraacija. jo tieshaam... nav viennoziimiiga identifikatora, peec kura noteikt, kam iisti pieder shis grozinjsh. nu var, protams, uzsetot cookiju ar groza_id... bet tas ir tieshaam garaam publiski lietojamo datoru gadiijumaa!

 

arii pirmajaa variantaa ir jaaruupeejas par piepildiitiem groziem, kas nav nopirkti! Bet nu te pietiek, teiksim, reizi diennaktii padzeest aaraa ierakstus no grozu tabulas, kuri vecaaki par kaadu nedeelju (nu meenesi, ja negribas, lai maniaki, kuri tur browseri atveertu gadiem no vietas, nesadusmotos).

Link to comment
Share on other sites

pirmais variants! Viennoziimiigi!

tipa tabula carts(sesijas_id,produkta_id,nopirktais_skaits,timestamp....)

Kad izdara pirkumu, sapuusham visu tabulaas

orders (prieksh infas par pasuutiitaaju (pasuutiitaaja rekviziiti, ip, laix...)) un order_details (ordera_id, produkta_id, cena_pirkshanas_briidii...)

 

otram variantam ir jeega tikai tad, ja ir regjistraacija. jo tieshaam... nav viennoziimiiga identifikatora, peec kura noteikt, kam iisti pieder shis grozinjsh. nu var, protams, uzsetot cookiju ar groza_id... bet tas ir tieshaam garaam publiski lietojamo datoru gadiijumaa!

 

arii pirmajaa variantaa ir jaaruupeejas par piepildiitiem groziem, kas nav nopirkti! Bet nu te pietiek, teiksim, reizi diennaktii padzeest aaraa ierakstus no grozu tabulas, kuri vecaaki par kaadu nedeelju (nu meenesi, ja negribas, lai maniaki, kuri tur browseri atveertu gadiem no vietas, nesadusmotos).

19053[/snapback]

būsi bik neprecīzi pirmo variantu sapratis - tb dati datubāzē ierakstās tikai tad, kad pircējs savada savus rekvizītus un ir gatavs ņemt preci(nav tabulas carts, pārējo laiku preču ID glabājas sesijas mainīgajos).

Link to comment
Share on other sites

būsi bik neprecīzi pirmo variantu sapratis - tb dati datubāzē ierakstās tikai tad, kad pircējs savada savus rekvizītus un ir gatavs ņemt preci(nav tabulas carts, pārējo laiku preču ID glabājas sesijas mainīgajos).

19055[/snapback]

 

Ok, laikam drusku paarpratu! Tomeer ir viens bet!

Ja Tev sesijaa ir tipa masiivs $grozs, kura elementi ir [preces_id, skaits] tad lai to atteelotu, Tev jaataisa:

 

foreach ($grozs as $e) {

 mysql_query("select * from products where prod_id=".$e['prod_id']);

 .....

}

 

Selekts ciklaaa pie katras groza ielaades!

Ja ir tabula carts, tad godiigi visu groza saturu var dabuut ar vienu selektu, attieciigi piejoinojot products pie carts.

Viens selekts straadaa aatraak nekaa selekti ciklaa (nav liekas skraidiishanas starp db & php)

 

Te gan risinaajums, manupraat, ir, kad preci nopeerk, sesijaa gruust nevis tikai vinjas ID, bet visu preci grozaa atteelojosho HTMLu - tad db vispaar nav jaaaiztiek, lai atteelotu grozu.

Link to comment
Share on other sites

$_SESSION['grozs']=array('preces_id'=>'papildinfo');

 

"SELECT * FROM tabula WHERE preces_id IN (".implode(',',array_keys($_SESSION['grozs']).")"

 

bet vispār jau jā - es glabāju vai nu "īso pierakstu", e.g. preces nosaukums ar linku, vai pat pārtveru HTMLu sessijas mainīgā ar ob_* un tikai laiku pa laikam (kad tiek pievienota jauna "prece") to atjaunoju.

atkarīgs no tā, cik info jāglabā

pie tam arī SQL pusē var nobuferot

Link to comment
Share on other sites

$_SESSION['grozs']=array('preces_id'=>'papildinfo');

 

"SELECT * FROM tabula WHERE preces_id IN (".implode(',',array_keys($_SESSION['grozs']).")"

 

bet vispār jau jā - es glabāju vai nu "īso pierakstu", e.g. preces nosaukums ar linku, vai pat pārtveru HTMLu sessijas mainīgā ar ob_* un tikai laiku pa laikam (kad tiek pievienota jauna "prece") to atjaunoju.

atkarīgs no tā, cik info jāglabā

pie tam arī SQL pusē var nobuferot

19063[/snapback]

 

Hmm... es gan nekad neesmu benchmarkojis taadu select.... in......, bet katraa zinjaa tieshaam tas arii noveersh selectus ciklaa.

A tas ob_* ir labs ar to, ka der jebkuram groza satura glabaashanas risinaajumam.

Diemzheel man biezhi ir taa, ka kaut ko optimizeet saaku tad, kad saakas probleemas :( Kad kaut ko baigi aatri vajag dabuut gatavu, paliek vietas kodaaa, kuraas ir pielietots pirmais risinaajums, kas ienaaca praataa. Bet nu neko -censhos no kljuudaam maaciities.

Link to comment
Share on other sites

Diemzheel man biezhi ir taa, ka kaut ko optimizeet saaku tad, kad saakas probleemas :(

19066[/snapback]

 

Uz šī grābekļa laikam gandrīz visi uzkāpuši - optimizēt vajag censties uzreiz, bet ar domu ka scripts jāpatru tīrs un flexibls - ar iespēju dajebko, dajebkad fixi pārtaisīt - tas tā iz sūrās pieredzes:)

Link to comment
Share on other sites

Uz šī grābekļa laikam gandrīz visi uzkāpuši - optimizēt vajag censties uzreiz, bet ar domu ka scripts jāpatru tīrs un flexibls - ar iespēju dajebko, dajebkad fixi pārtaisīt - tas tā iz sūrās pieredzes:)

19082[/snapback]

 

Zinu :) Bet taa pieredze naak kaa siipola mizas - pa iteraacijaam un ar visaam asaraam :) Tas, kas pirms 2 gadiem likaas uberkruts risinaajums, tagad izraadaas ir galiigais sviesc :)

Bet taa es pilniibaa piekriitu. Galvenais ir panaakt situaaciju, ka izmainju veikshanai nepiecieshams mainiit vislabaakajaa gadiijumaa tikai vienu funkciju/ konstanti/ierakstu metadatu tabulaa, nevis skraidiit cauri visam projektam. Bet reizeem ir nezheeliigs slinkums taisiit 2 rindu fju, taa vietaa lai fixi labaak paarcopypastotu. Un veel viena lieta - jaataisa taa, lai arii peec gada atverot, pac vareetu saprast, kaa tas sataisiitais straadaa :) Discipliina viennoziimiigi ir jaaieveero.

Link to comment
Share on other sites

×
×
  • Create New...