Sessione HTTP o approccio al database


16

Sono un po 'confuso come quello che dovrebbe essere il mio approccio, sto lavorando su un progetto di carrello della spesa e ho bisogno di archiviare il carrello in sessione o nel database ma non sono sicuro di quale approccio sarebbe meglio. Ci sono i casi d'uso

  1. L'utente non ha effettuato l'accesso e ha aggiunto il prodotto al carrello (Utente anonimo)
  2. L'utente ha effettuato l'accesso e ha aggiunto il prodotto al carrello.

Il primo caso è più confuso per me, dal momento che ci possono essere molti casi in cui l'utente sta semplicemente visitando il web-shop e aggiungendo il prodotto senza effettuare il login e può essere del tutto possibile che non vada per una procedura di pagamento.

Ma dobbiamo ancora creare un carrello per questo utente, al fine di creare e salvare il carrello ho due opzioni.

  1. Quando l'utente aggiunge un prodotto, crea un carrello nel database e associa questo carrello a questo utente, nel momento in cui ha effettuato l'accesso sposta questo carrello in utente connesso.
  2. Crea carrello, aggiungi prodotto e salvalo nella Sessione, quando l'utente ha effettuato l'accesso crea Carrello nel database e l'utente connesso con questo carrello con Utente.

So che sia il sistema Cart basato su database sia basato sulla sessione possono avere aspetti positivi e negativi, ma non sono sicuro di quale potrebbe essere l'approccio migliore prendendo in considerazione i seguenti punti

  1. scalabilità
  2. Flessibilità
  3. Estensibilità
  4. Applicazione Dovrebbe occuparsi della velocità

In cerca di input su questo aspetto per decidere il percorso.


2
Perché? Gestisco diverse centinaia di siti Web di e-commerce e archiviamo tutto in cookie o localStorage (HTML5). Inoltre, le sessioni consumano memoria. Quando effettuiamo l'accesso all'account, utilizziamo un cookie crittografato con un timestamp. Non abbiamo bisogno di una sessione perché quando una pagina viene caricata, utilizziamo le tecniche HTML5 per archiviare e utilizzare sessionStorage dopo un singolo caricamento. Questa è la tecnologia web standard compatibile IE8 +.
Jason Sebring,

@LuiggiMendoza ok, perché no.
Jason Sebring,

@ zipstory.com: vorrei anche dare un'occhiata alla soluzione basata su HTML5, ma dato che non è supportato da pochi browser, sono un po 'dubbioso
Umesh Awasthi

@UmeshAwasthi Suppongo che i miei clienti non si preoccupino della piccola manciata di persone con browser inferiori, ma ovviamente questo è un cattivo approccio se si tratta di un caso diverso nel tuo traffico web. So che molti del mondo usano XP su IE7 e talvolta IE6, ma alcuni dei miei prodotti per i miei clienti si trovano in negozi come Nordstroms e Macy's ecc. E sembrano non preoccuparsene.
Jason Sebring,

@ zipstory.com: sto lavorando con un'applicazione di eCommerce in cui il cliente desidera anche supporto per IE6, ora cosa ne dirai :) :)
Umesh Awasthi

Risposte:


9

Vorrei cercare una soluzione in cui un ID univoco viene assegnato a tutti i visitatori quando accedono per la prima volta al sito. Non importa se sono anonimi o autenticati. Quando gli utenti anonimi si registrano, conservare l'ID univoco.

Conservare il carrello nel database. Lo spazio di archiviazione è economico e non dovrebbe essere un problema dal punto di vista delle prestazioni eseguire una query per il carrello di tanto in tanto.


che dire di quando devo mostrare la pagina dei dettagli del carrello? dovremmo archiviare / recuperare i dati dalla sessione o cercare un hit nel database?
Umesh Awasthi,

Se si memorizzano i dettagli del carrello nel database, quindi sì, è necessario colpire il database.
Jakob Gade,

7

Entrambi i metodi presentano vantaggi e svantaggi, ma per come la vedo io, l'archiviazione del database ha due vantaggi piuttosto grandi.

  1. Segnalazione. Non è possibile generare rapporti su carrelli abbandonati, tassi di conversione, ecc. Se i dati sono presenti nella sessione.
  2. Timeout della sessione. Sarei infastidito se andassi a cena e tornassi per scoprire che il mio carrello è stato svuotato perché la sessione è scaduta. Immagino che neanche al rivenditore piacerà. Vogliamo spingere l'utente verso l'acquisto, non verso la rinuncia e la partenza.

6

La domanda è presumere che abbiate bisogno di sessioni che non sono necessarie nel mio mercato di clienti. Mi capita di gestire diverse centinaia di siti Web di e-commerce e una manciata di essi sta ricevendo traffico intenso. Non usiamo mai le sessioni in quanto non sono scalabili a meno che non siano allevate, quindi sono solo più lente o richiedono una maggiore configurazione. Le sessioni consumano memoria e il recupero del database dello stato della sessione è molto lento e richiede più parti mobili.

Al contrario, utilizziamo HTML5 sessionStorage per rendere persistenti le informazioni sugli utenti che dobbiamo estrarre ripetutamente, ma senza la necessità di un rountrip di cookie ogni volta per aumentare la larghezza di banda. Questo è IE8 + e tutti gli altri browser e dispositivi mobili moderni sono compatibili con questa tecnologia. MA potresti semplicemente archiviare il carrello in un cookie come fallback poiché questo è ciò che abbiamo fatto in precedenza. Ecco un buon carrello dei cookie: http://simplecartjs.org/

Quando gli utenti accedono o effettuano l'accesso, utilizziamo un cookie crittografato con un timestamp inserito.

Stiamo anche procedendo verso l'utilizzo di ApplicationCache laddove applicabile, il che ridurrà ulteriormente il traffico Web come nota a margine poiché è possibile precaricare le risorse e persino catalogare i dati in modo che la prospettiva dell'utente sia un sito Web a caricamento superveloce e il cellulare funzionerà anche offline (meno le transazioni). Ovviamente devi stare attento ad aggiornare il manifest quando cambiano i prodotti ecc.


4

Si presuppone che l'archiviazione della sessione e l'archiviazione del database siano esclusivi. Non lo sono. Ma partiamo dal presupposto che lo siano.

Il vantaggio della memorizzazione delle sessioni è triplice:

  1. Non è necessario inserire esplicitamente i dati nel database. Basta semplicemente impostare una variabile di sessione e il gioco è fatto. Funzionalmente semplice ea basso rischio.
  2. Non è necessario gestire il ciclo di vita di una visita dell'utente e del carrello degli acquisti poiché i contenitori / framework lo fanno per te
  3. Solitamente la pulizia automatica delle vecchie sessioni inattive viene eseguita per te.

Svantaggi dell'archiviazione delle sessioni:

  1. Affinità di sessione, a meno che non si analizzi la replica
  2. Nessun failover, a meno che non si analizzi la replica o la persistenza manuale dello stato della sessione su disco, il che può complicarsi.
  3. Tutte le sessioni devono essere archiviate in memoria. Questo è amplificato se si utilizza la replica.

Vantaggi dell'archiviazione del database:

  1. Non è necessario preoccuparsi dell'affinità della sessione o della replica dello stato. Puoi eseguire il round robin di tutte le richieste.
  2. Meno sovraccarico di memoria nell'applicazione.
  3. Se l'ordine è completato, tutto finisce comunque nel database, quindi questo potrebbe rendere il completamento facile perché i dati sono già presenti.

Svantaggi dell'archiviazione del database:

  1. Carrelli abbandonati: alcuni utenti anonimi hanno aggiunto un articolo al carrello e sono scomparsi. I dati restano per sempre a meno che tu non abbia una sorta di processo di scadenza.
  2. Devi trovare un modo per tracciare gli utenti e capire se, per una determinata richiesta, ciò rappresenta una sessione di navigazione esistente o nuova. (sì, probabilmente è facile se si utilizza un cookie, ma come si fa a garantire che due utenti non finiscano con lo stesso ID?).
  3. Più codice

Non hai menzionato quale piattaforma stai utilizzando. Vorrei cercare un approccio che utilizza una sessione supportata dal database in cui i dati della sessione esistono solo in memoria durante la vita di un ciclo di richiesta / risposta, caricandoli dal database e salvandoli nel database. Questo mi è servito bene in passato.

Vantaggi di una sessione supportata da database:

  1. Non è necessaria l'affinità del server.
  2. Facile sulla memoria del server app
  3. I dati della sessione inattiva / abbandonata vengono ripuliti per te.
  4. Il ciclo di vita della prima visita dell'utente, la visita ripetuta, la fine della sessione è tutto pensato per te.
  5. Facile da codificare

Svantaggi di una sessione supportata da database:

  1. Configurazione: è necessario esaminare il contenitore, che si tratti di PHP, Java EE (Tomcat, Jetty, JBoss, ecc.), Node.js + express.js o quant'altro che supporti questo e fornisca la giusta configurazione.
  2. Potrebbe essere necessario caricare questo test poiché si stanno aggiungendo 2 operazioni del database per richiesta.

C'è una terza possibilità, che qualcuno ha toccato prima. È possibile saltare del tutto l'uso delle sessioni e utilizzare l'archiviazione sul lato client incorporando tutto in un cookie o nell'archiviazione locale HTML.

Lascerò i pro / contro di ciò come un esercizio per te, ma ti darò un suggerimento che per l'archiviazione html5, la compatibilità del browser potrebbe essere qualcosa da rivedere attentamente.

Ho delineato i fatti per te. Spero che questo ti aiuti a prendere la decisione giusta per la tua situazione.


Hai perso un vantaggio dell'archiviazione del database, abilmente dell'organizzazione per analizzare i tassi di acquisto delle cose inserite nei carrelli della spesa.
HLGEM,

@HLGEM Ottima idea - Non ci avevo mai pensato!
Brandon,

Penso a queste cose perché sono io quello che fa l'analisi dei dati nel database. Quando si progettano database, una delle prime domande dovrebbe essere per cosa avremo bisogno di questi dati e quasi nessuno li chiede mai.
HLGEM,

3

Consideriamo i due casi d'uso che hai citato

L'utente non ha effettuato l'accesso e ha aggiunto il prodotto al carrello (Utente anonimo)

In questo caso, si desidera sicuramente salvare le informazioni del carrello dell'utente in una sessione per servire l'utente durante la sua sessione. Se decide di accedere / creare un account, è possibile gestirlo in base al caso d'uso successivo. Se lui / lei non accede, non è necessario riempire il database con le informazioni di questo ospite poiché è stato utilizzato solo per servire l'ospite durante la sessione. Questi dati possono essere gestiti su base Stateless, ovvero non lo stato non viene salvato da sessione a sessione.

L'utente ha effettuato l'accesso e ha aggiunto il prodotto al carrello.

In questo caso, puoi gestirli come sopra (siti di e-commerce della vecchia scuola) e anche aggiungere queste informazioni al database e associarle all'utente. Viene utilizzato principalmente per fornire informazioni stateful (stato salvato da sessione a sessione) come "Cronologia esplorazioni prodotti", "Consigli" ecc. Simili ad Amazon.com.

Cose a cui pensare:

  • È necessario salvare i dati?
  • In caso affermativo, quali sono i dati più importanti da salvare per servire meglio l'utente?
  • Scalabilità + archiviazione dati - Come salverai le informazioni del carrello per una rapida ricerca nel tuo database per supportare molti utenti?

3
Aiuta anche l'azienda ad analizzare le vendite. Con quale frequenza un prodotto viene inserito in un carrello ma non acquistato. Se la percentuale è alta, potrebbero voler esaminare come viene presentato il prodotto o il prezzo per vedere se le modifiche possono aiutare a migliorare il tasso di acquisto. Il salvataggio può anche consentire all'utente di vedere rapidamente quegli articoli se non ha ordinato tehm il giorno in cui ha guardato piuttosto che cercarli di nuovo. Quindi forse li hai messi nel carrello ma volevi aspettare fino a domani (giorno di paga) per acquistarli effettivamente. Pertanto, il salvataggio dei dati potrebbe comportare l'acquisto da parte dei clienti reali di più prodotti.
HLGEM

Ma alla fine questo è un problema di definizione dei requisiti e dovresti dire alla tua azienda cosa pensi di fare e assicurarti che sia quello che si aspettano prima di costruire qualcosa.
HLGEM

Ricorda che devi pensare all'ordine e ai carrelli della spesa dal punto di vista di ciò che l'azienda potrebbe aver bisogno dei dati per il futuro. Se vogliono analizzare i dati, è meglio archiviarli. Gli sviluppatori si bloccano sull'interfaccia utente e dimenticano lo scopo dei dati di essere archiviati durante la progettazione.
HLGEM

@HLGEM: ottimo punto! Ho risposto a questa domanda semplicemente basandomi sulla necessità di supportare la funzionalità dell'auto per un utente ospite rispetto a un membro del sito. Da un punto di vista commerciale, dovrebbe esserci un sistema statistico separato che dipende da una sorta di sistema di database che tiene traccia dei prodotti in termini di geografia, numero di utenti, prodotti correlati, acquisto contro scarti, ecc.
GeekByte

0

Vai alla sessione quando l'utente non ha effettuato l'accesso. Anche quando hai effettuato l'accesso, crea prima il carrello nella sessione e persistilo nel database solo quando l'utente si disconnette o la sessione scade.

Devi tenere sotto controllo il numero di carrelli creati nella sessione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.