Newsgroup: it.comp.www.php
Titolo: consiglio - carrello sito e-com

salve,
devo realizzare un carrello della spesa
devo decidere fra alcune soluzioni
1) db o sessioni ?
ricordo che tempo fa qualcuno aveva fatto una domanda simile quindi andrò a 
rileggerla poi magari
ri-posto.
ma vorrei sapere, nel caso che decidessi, di utilizzare le sessioni , come 
la "strutturate"
la variabile di sessione ? usate un array associativo , con le varie parti 
sotto array etc (per gestire i vari articoli )
oppure c'è qualche altro tricks che si può utilizzare  ?
grazie ciao.

 rileggerla poi magari
Nella maggior parte dei siti ecommerce i carrelli della spesa sono
persistenti, ovvero rimangono gli item dentro il carrello finchè l'utente
non svuota il carrello o finchè l'utente non acquista, indipendentemente dal
giorno in cui l'utente si autentica ("oggi riempio il carrello, domani
pago").
Un sistema di questo tipo si può fare esclusivamente con il database, le
sessioni non sono sufficienti.
Se si esclude questa funzionalità non vedo alcuna ragione per prediligere i
database rispetto alle sessioni, ma aspettiamo altri commenti.

 ha scritto nel messaggio 
news:OAc2e.1130817$35.42...@news4.tin.it...

ok ma con le sessioni come fai a gestire "le righe" del carrello ? (per 
eliminazione, modifica, aggiunta)...
io aspetto :-) 

 eliminazione, modifica, aggiunta)...
Con un array che associa a ciascun indice numerico, la quantità desiderata e
l'identificativo del prodotto nel database.
E poi ci fai quello che vuoi.
Io comunque preferirei i database.

 ha scritto nel messaggio 
news:t5f2e.710957$b5.32...@news3.tin.it...

non so sto leggendo parecchi vecchi post nel ng sto andando sempre di più 
sulle session ma la bilancia ancora
non ha terminato di oscillare quindi si vedrà .
La paura del db e che prima o poi scoppia :| a lungo andare si superano i 
limiti fisici proprio del db....
per il resto avrei anche "Superato" il problema dello spooling...  in ogni 
caso tutto il codice per gestire gli array
se voglio fare le cose fatte bene lo devo scrivere , in questo modo potrei 
usarlo in entrambi i casi
e tutto in testa ancora leggerò ancora qualcosa prima di tirar fuori 
conclusioni...
r
--

 limiti fisici proprio del db....
Oddio, cosa devi riprodurre? Amazon? :)
Basta progettarlo bene. Per dire due cazzate, fai una tabella "carrelli"
con identry, idutente, idoggetto, quantita. Indicizzi idutente. Le
ricerche diventano istantanee. Se hai una tabella "oggetti" con
idoggetto indicizzato, anche l'associazione carrello-oggetto diventa
istantanea.
Limiti fisici nei DB e` difficile raggiungerli. Anche usando id a 32
bit, devi infilarne uno al secondo per un centinaio di anni di fila
prima di riempire il DB. Certo, se conti di avere una decina di
inserimenti al secondo nel DB, devi pensare di usare indici a 64 bit,
dischi a frotte e magari anche cluster di macchine, ma a quel punto ti
ripaghi tranquillamente il tutto con le vendite del sito.
Poi, se usi Access, i limiti li raggiungi subito... :P
Bye.
-- 
Alessandro Pellizzari

 bit, devi infilarne uno al secondo per un centinaio di anni di fila
questo risultato come l'hai calcolato :) curiosità...

 questo risultato come l'hai calcolato :) curiosità...
Il timestamp Unix e` a 32 bit signed. Conta i secondi dal 1 gennaio
1970, e nel 2038 iniziera` ad andare in negativo. Sono 68 anni, quindi
136 anni perche` e` signed e tu lo usi unsigned.
Per fare i conti fai presto. Un numero a 32 bit tiene circa 4 miliardi
di valori. Dividi per 60*60*24*365.2 e ottieni il numero di anni (circa
136, appunto)
Bye.
-- 
Alessandro Pellizzari

 ha scritto nel messaggio 
news:1112118205.2...@namek.capsule.lan...




Sarò giò morto cazzi del cliente vada per il db :-)

 limiti fisici proprio del db....
Ah beh se non sai progettare i database fai bene a usare le sessioni.
Fammi fare due conti, MySql dovrebbe gestire senza troppi problemi tabelle
nell'ordine di decine di milioni di record, una decina di articoli per
carrello significa qualche milione di clienti con il carrello aperto. Con
questi numeri ti conviene passare ad Oracle e farti installare dei server
IBM oppure Sun, tanto te lo puoi permettere.

 questo risultato come l'hai calcolato :) curiosità...
anni necessari ad esaurire gli id a 32 bit immettendo una riga al secondo =
2^32 / (60*60*24*365) = 136
anni necessari ad esaurire gli id a 64 bit immettendo una riga al secondo =
2^64 / (60*60*24*365) = 585*10^9
In effetti 136 anni sono un po' pochini, considerando i progressi
scientifici rischi di essere ancora in vita.
D'altra parte il programma che avrai sviluppato avrà esaurito il suo ciclo
di vita almeno 20 volte......
Per quanto riguarda gli id a 64 bit probabilmente bastano fino alla fine
dell'universo.

 IBM oppure Sun, tanto te lo puoi permettere.
Ho parlato di soldi ? ho detto che me lo posso permettere ...Non mi pare
termino qua va :)
r
---