panier pour les utilisateurs non enregistrés

Question

Je suis en train de faire un site Web qui implique un panier. Il y a deux exigences majeures:

1. Les gars d'expérience utilisateur veulent se connecter/authentification à la dernière étape du flux de travail complet. L'utilisateur doit faire tous les achats et est invité à se connecter uniquement au moment de la sortie.

2. Le panier ne doit pas expirer (même pas à la fermeture du navigateur), sauf si l'utilisateur (enregistré ou non) s'enregistre.

Dans le contexte ci-dessus, je pose la question suivante en ce qui concerne le maintien de l'état du panier:

Dois-je aller avec des sessions de fichiers à base ou la base de données? S'il vous plaît gardez à l'esprit que ce serait pour les utilisateurs non enregistrés. Mon appréhension est que je finirai par avoir beaucoup de dossiers dans la base de données.

Une autre option semble être de mettre le contenu du panier dans un cookie chiffré, mais il y a une limitation de taille sur le fichier cookie.

Que feriez-vous dans ce cas? J'apprécierais vraiment vos réponses.

Answer 1

1. Suivi d'un utilisateur. Utilisez un GUID codé dans un cookie avec un n Année d'expiration.

2. Stockage d'un panier. Vous ne voulez pas stocker le sac dans le cookie, principalement en raison de sa taille possible. Cela laisse l'option de le persister dans un milieu et de le récupérer du milieu.Utiliser quoi que ce soit à l'exception d'une base de données serait comme remonter le temps, les bases de données excellent pour stocker et récupérer des données.

3. Gestion de votre panier. Maintenant, la question de votre schéma, d'une part, si vous allez être requêtes en cours d'exécution contre les sacs dans la base de données (combien achats sacs contiennent article x) vous avez probablement voulez un relationnel traditionnel schéma . Cependant, cela a des frais généraux en termes d'insertion. mise à jour, sélection (et rejoindre) et suppression des données de sac (à un certain point, vous aurez sacs qui ne seront plus jamais utilisés mais qui prennent de précieux disque espace). Avec un site occupé, il s'agit d'un juste quelques Traranactions par seconde, mais toute base de données devrait être capable de faire face. Si vous n'avez pas besoin d'interroger les sacs dans la base de données, alors vous pouvez le stocker en XML. Juste sérialiser le sac et le vider dans une table , avec le PK comme GUID comme stocké dans le cookie des utilisateurs. Ce serait beaucoup plus rapide qu'un schéma traditionnel , plus vous pourriez toujours déchirer le code XML dans le futur si un besoin est venu pour un schéma relationnel.

C'est ce que nous faisons (Xml Bag), et nous avons un million de clients + base.

Answer 2

J'irais avec des sessions de bases de données gérées sur des sessions gérées par des fichiers. Assurez-vous d'avoir un horodatage de session afin de pouvoir éventuellement tuer les vieilles sessions (si cela fait 12 mois, le client ne reviendra peut-être pas pour les articles initialement dans le panier). Si vous faites cela avec une base de données au lieu de fichiers, il sera plus facile d'expirer les très vieilles informations par la suite.

Notez que la session de la base de données ne sera valide que tant que le cookie auquel elle est associée sur l'ordinateur de l'utilisateur. Si l'utilisateur revient au magasin à partir d'un navigateur différent, il ne trouvera pas sa session. Si deux personnes partagent le même ordinateur, elles trouveront la session de l'autre. Espérons qu'aucun élément potentiellement embarrassant ne sera dans le panier ...

Answer 3

Stockez dans les cookies le AnonymousSessionID, avec lequel vous associez un panier dans la base de données.

Ensuite, vous aurez une tâche de planificateur pour effacer les sessions anonymes après un certain temps (par exemple, un jour). Cela gardera votre base de données propre des sessions abandonnées.

Si un utilisateur s'enregistre, vous réassociez son panier avec son compte de manière permanente. Si les utilisateurs passent une commande, vous videz leur panier.

Answer 4

Avec ces spécifications j'irais avec un état de session basé sur la base de données. Mais vous devriez faire une lecture lourde sur comment l'état de la session est géré dans votre serveur web de choix. Puisque vous voulez être en mesure de faire revivre l'état à la bonne personne.

Answer 5

Si vous utilisez ASP.NET est ici ce que je suis (environ) à faire:

• utiliser un Profile pour capturer les utilisateurs e-mail dès que possible (pour les envoyer par courriel si elles ne le remplir commande). vous pouvez activer les propriétés de profil anonymes qui sont conservées dans la base de données aspnet même si l'utilisateur n'est pas réellement enregistré.
• coller un sac XML représentant un ordre dans la session. Ceci est conservé dans la base de données avec un identifiant d'identité régulier.
• stockez l'ID du chariot dans ASP.NET Profile. Ainsi, lorsque la session expire, vous pouvez simplement la recharger à partir de l'ID du profil. Ceci a l'avantage que l'utilisateur ne voit jamais l'ID du panier dans un cookie et que vous pouvez facilement lier les enregistrements entre la base de données d'appartenance/profil et le magasin que vous utilisez pour vos commandes

(ne pas essayer de stocker le XML ordre dans le profil. Je pense que c'est demander des problèmes de performance, mais en théorie, vous pourriez je suppose)

Answer 6

Je pense que vous avez des attentes à gérer, ou peut-être que vous n'étiez pas clair sur les exigences.

1. Les gars de l'expérience utilisateur veulent se connecter/authentification pour être le dernière étape dans le flux de travail complet. L'utilisateur doit faire tous les achats et est invité à se connecter uniquement au moment de la vérification .
2. Le panier ne doit pas expirer (pas même lors de la fermeture du navigateur) sauf si l'utilisateur (enregistré ou non) vérifie.

Plus précisément, un anonyme, non connecté dans le panier de l'utilisateur étant sauvé? C'est de la folie. Assurez-vous que ce n'est pas une attente et clarifiez-le dans vos documents de conception.