lame Posted July 4, 2005 Report Share Posted July 4, 2005 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 More sharing options...
Venom Posted July 4, 2005 Report Share Posted July 4, 2005 1ais. Pēc apstiprināšanas - tabulā atskaitēm. Link to comment Share on other sites More sharing options...
Delfins Posted July 4, 2005 Report Share Posted July 4, 2005 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 More sharing options...
v3rb0 Posted July 4, 2005 Report Share Posted July 4, 2005 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 More sharing options...
Venom Posted July 4, 2005 Report Share Posted July 4, 2005 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 More sharing options...
lame Posted July 4, 2005 Author Report Share Posted July 4, 2005 1ais. Pēc apstiprināšanas - tabulā atskaitēm. 18990[/snapback] Paldies, par ieteikumu! :) Domājams, ka palikšu pie 1. varianta. Link to comment Share on other sites More sharing options...
Delfins Posted July 4, 2005 Report Share Posted July 4, 2005 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 More sharing options...
des Posted July 5, 2005 Report Share Posted July 5, 2005 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 More sharing options...
lame Posted July 5, 2005 Author Report Share Posted July 5, 2005 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 More sharing options...
des Posted July 6, 2005 Report Share Posted July 6, 2005 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 More sharing options...
Venom Posted July 6, 2005 Report Share Posted July 6, 2005 $_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 More sharing options...
des Posted July 6, 2005 Report Share Posted July 6, 2005 $_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 More sharing options...
v3rb0 Posted July 6, 2005 Report Share Posted July 6, 2005 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 More sharing options...
des Posted July 6, 2005 Report Share Posted July 6, 2005 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 More sharing options...
Recommended Posts