Session HTTP ou approche de base de données
Je suis un peu confus quant à ce que devrait être mon approche, travaillant sur une conception de panier d'achat et j'ai besoin de stocker le panier d'achat en session ou dans la base de données, mais je ne sais pas quelle approche serait la meilleure.
- L'utilisateur n'est pas connecté et ajoute un produit au panier (utilisateur anonyme)
- L'utilisateur est connecté et ajoute un produit au panier.
Le premier cas est plus déroutant pour moi, car il peut y avoir de nombreux cas où l'utilisateur vient de visiter une boutique en ligne et d'ajouter un produit sans se connecter et il est tout à fait possible qu'il ne passe pas par un processus de paiement.
Mais nous devons toujours créer un panier pour cet utilisateur, afin de créer et enregistrer le panier, j'ai deux options.
- Lorsque l'utilisateur ajoute un produit, créez un panier dans la base de données et associez ce panier à cet utilisateur, au moment où il s'est connecté, déplacez ce panier vers l'utilisateur connecté.
- Créer un panier, y ajouter un produit et l'enregistrer dans la session, lorsque l'utilisateur connecté crée un panier dans la base de données et l'utilisateur connecté associé à ce panier avec l'utilisateur.
Je sais que le système de panier basé sur la base de données et la session peuvent avoir des aspects positifs et négatifs, mais je ne sais pas lequel pourrait être la meilleure approche en tenant compte des points suivants
- Évolutivité
- Souplesse
- Extensibilité
- L'application doit prendre soin de la vitesse
Vous cherchez des commentaires sur cet aspect pour décider du chemin.
J'irais pour une solution où un identifiant unique est attribué à tous les visiteurs lors de leur première visite sur le site. Peu importe qu'ils soient anonymes ou authentifiés. Lorsque des utilisateurs anonymes s'enregistrent, conservez l'ID unique.
Stockez le panier dans la base de données. Le stockage est bon marché, et cela ne devrait pas être un problème en termes de performances de faire une requête pour le panier de temps en temps.
Les deux méthodes ont des avantages et des inconvénients, mais selon moi, le stockage de base de données présente deux avantages assez importants.
- Rapports. Vous ne pouvez pas générer de rapport sur les paniers abandonnés, les taux de conversion, etc. si les données se trouvent dans la session.
- Délais d'expiration de session. Je serais ennuyé si j'allais dîner et revenais pour découvrir que mon panier avait été vidé parce que la session était expirée. J'imagine que le détaillant n'aimerait pas ça non plus. Nous voulons pousser l'utilisateur à acheter, pas à abandonner et à partir.
La question est de supposer que vous avez besoin de sessions, ce qui n'est pas nécessaire sur mon marché de clients. Il se trouve que je gère plusieurs centaines de sites Web de commerce électronique et qu'une poignée d'entre eux reçoivent un trafic élevé. Nous n'utilisons jamais de sessions car elles ne sont pas évolutives sauf si elles sont développées, elles sont simplement plus lentes ou nécessitent plus de configuration. Les sessions utilisent de la mémoire et l'extraction de la base de données de l'état de session est très lente et nécessite davantage de pièces mobiles.
Au lieu de cela, nous utilisons HTML5 sessionStorage pour conserver toutes les informations utilisateur dont nous avons besoin de tirer encore et encore, mais sans avoir besoin d'un rountrip de cookie à chaque fois pour augmenter la bande passante. Il s'agit d'IE8 + et tous les autres navigateurs et appareils mobiles modernes sont compatibles avec cette technologie. MAIS vous pouvez simplement stocker le panier dans un cookie comme solution de rechange, comme c'est le cas précédemment. Voici un bon panier de cookies: http://simplecartjs.org/
Lorsque les utilisateurs se connectent ou se connectent, nous utilisons un cookie crypté avec un horodatage intégré.
Nous nous dirigeons également vers l'utilisation d'ApplicationCache, le cas échéant, ce qui réduira davantage le trafic Web en tant que note secondaire, car vous pouvez pré-extraire des ressources et même des données de catalogue, de sorte que la perspective de l'utilisateur sera un site Web à chargement ultra rapide et le mobile fonctionnera également hors ligne (transactions moins). Bien sûr, vous devez faire attention à mettre à jour le manifeste lorsque les produits changent, etc.
Vous supposez que le stockage de session et le stockage de base de données sont exclusifs. Ils ne le sont pas. Mais commençons par supposer qu'ils le sont.
L'avantage du stockage de session est triple:
- Pas besoin d'insérer explicitement des données dans la base de données. Vous définissez simplement une variable de session et vous avez terminé. Fonctionnel simple et à faible risque.
- Pas besoin de gérer le cycle de vie d'une visite utilisateur et d'un panier d'achat car les conteneurs/frameworks le font pour vous
- Habituellement, le nettoyage automatique des anciennes sessions inactives est fait pour vous.
Inconvénients du stockage de session:
- Affinité de session, sauf si vous étudiez la réplication
- Pas de basculement, sauf si vous étudiez la réplication ou la persistance manuelle de l'état de la session sur le disque, ce qui peut devenir compliqué.
- Toutes les sessions doivent être stockées en mémoire. Ceci est amplifié si vous utilisez la réplication.
Avantages du stockage de la base de données:
- Pas besoin de vous soucier de l'affinité de session ou de la réplication d'état. Vous pouvez effectuer un tour de rôle pour toutes les demandes.
- Moins de surcharge de mémoire dans l'application.
- Si la commande est terminée, tout finit de toute façon dans la base de données, ce qui pourrait faciliter la finalisation car les données sont déjà présentes.
Inconvénients du stockage de base de données:
- Chariots abandonnés - un utilisateur anonyme a ajouté un article à son panier et a disparu. Ces données restent éternelles, sauf si vous avez une sorte de processus d'expiration.
- Vous devez trouver un moyen de suivre les utilisateurs et de déterminer si, pour une demande donnée, cela représente une session de navigation existante ou nouvelle. (oui, c'est probablement facile si vous utilisez un cookie, mais comment vous assurez-vous que deux utilisateurs ne se retrouvent pas avec le même identifiant?).
- Plus de code
Vous n'avez pas mentionné la plateforme que vous utilisez. Je rechercherais une approche qui utilise une session basée sur une base de données où les données de session n'existent qu'en mémoire pendant la durée d'un cycle de demande/réponse, en les chargeant à partir de la base de données et en les sauvegardant dans la base de données. Cela m'a bien servi dans le passé.
Avantages d'une session basée sur une base de données:
- Pas besoin d'affinité de serveur.
- Facile sur la mémoire du serveur d'applications
- Les données de session inactive/abandonnée sont nettoyées pour vous.
- Le cycle de vie de la première visite de l'utilisateur, la visite répétée, la fin de la session est tout compris pour vous.
- Facile à coder
Inconvénients d'une session basée sur une base de données:
- Configuration - vous devez enquêter sur votre conteneur, qu'il s'agisse de PHP, Java EE (Tomcat, Jetty, JBoss, etc.), node.js + express.js ou quoi que ce soit le prendre en charge et fournir le bon configuration.
- Vous devrez peut-être le tester car vous ajoutez 2 opérations de base de données par demande.
Il y a une troisième possibilité, que quelqu'un a évoquée plus tôt. Vous pouvez ignorer l'utilisation des sessions et utiliser le stockage côté client en intégrant tout dans un cookie ou en stockage local html.
Je vais vous laisser les avantages/inconvénients comme un exercice, mais je vais vous donner un indice que pour le stockage html5, la compatibilité du navigateur peut être quelque chose à examiner attentivement.
Je vous ai expliqué les faits. J'espère que cela vous aidera à prendre la bonne décision pour votre situation.
Examinons les deux cas d'utilisation que vous avez mentionnés
L'utilisateur n'est pas connecté et ajoute un produit au panier (utilisateur anonyme)
Dans ce cas, vous souhaitez certainement enregistrer les informations du panier de l'utilisateur dans une session pour bien servir l'utilisateur pendant sa session. S'il décide de se connecter/créer un compte, vous pouvez gérer cela en fonction du prochain cas d'utilisation. S'il ne se connecte pas, vous n'avez pas besoin de remplir votre base de données avec les informations de cet utilisateur invité car elles n'ont été utilisées que pour servir l'invité pendant la session. Ces données peuvent être traitées sur une base sans état, c'est-à-dire que l'état n'est pas enregistré d'une session à l'autre.
L'utilisateur est connecté et ajoute un produit au panier.
Dans ce cas, vous pouvez les gérer de la même manière que ci-dessus (sites de commerce électronique à l'ancienne) et également ajouter ces informations à la base de données et les associer à l'utilisateur. Ceci est principalement utilisé pour fournir des informations avec état (état enregistré de session en session) telles que "Historique de navigation du produit", "Recommandations", etc., par exemple similaires à Amazon.com.
Points à considérer:
- Est-il nécessaire de sauvegarder des données?
- Si oui, quelles données sont les plus importantes à sauvegarder pour mieux servir l'utilisateur?
- Évolutivité + stockage de données - Comment allez-vous enregistrer les informations du panier pour une recherche rapide dans votre base de données pour prendre en charge de nombreux utilisateurs?
Optez pour la session lorsque l'utilisateur n'est pas connecté. Même lorsqu'il est connecté, créez d'abord le panier dans la session et conservez-le dans la base de données uniquement lorsque l'utilisateur se déconnecte ou que la session expire.
Vous devez contrôler le nombre de chariots créés dans la session.