HTTP-Sitzungs- oder Datenbankansatz

Ich bin ein wenig verwirrt darüber, wie ich vorgehen soll. Ich arbeite an einem Design des Einkaufswagens und muss den Einkaufswagens entweder in einer Sitzung oder in einer Datenbank speichern, bin mir aber nicht sicher, welcher Ansatz der beste ist

1. Benutzer ist nicht angemeldet und legt ein Produkt in den Warenkorb (Anonymer Benutzer)
2. Der Benutzer ist angemeldet und legt ein Produkt in den Warenkorb.

Der erste Fall ist für mich verwirrender, da es viele Fälle geben kann, in denen der Benutzer nur den Webshop besucht und Produkte hinzufügt, ohne sich anzumelden, und es durchaus möglich ist, dass er nicht zur Kasse geht.

Aber wir müssen noch einen Warenkorb für diesen Benutzer erstellen, um einen Warenkorb zu erstellen und zu speichern, habe ich zwei Möglichkeiten.

1. Wenn ein Benutzer ein Produkt hinzufügt, erstellen Sie einen Warenkorb in der Datenbank und ordnen Sie diesen Warenkorb diesem Benutzer zu, sobald er angemeldet ist. Verschieben Sie diesen Warenkorb zu dem angemeldeten Benutzer.
2. Einkaufswagen erstellen, Produkt hinzufügen und in der Sitzung speichern, wenn der Benutzer angemeldet ist. Einkaufswagen in der Datenbank erstellen und den angemeldeten Benutzer mit diesem Einkaufswagen mit Benutzer verknüpfen.

Ich weiß, dass sowohl das datenbankgesteuerte Cart-System als auch das sitzungsbasierte sowohl positive als auch negative Aspekte haben können, aber nicht sicher sind, welcher Ansatz unter Berücksichtigung der folgenden Punkte der beste ist

1. Skalierbarkeit
2. Flexibilität
3. Erweiterbarkeit
4. Anwendung Sollte auf Schnelligkeit achten

Suchen Sie nach Informationen zu diesem Aspekt, um den Pfad zu bestimmen.

Ich würde mich für eine Lösung entscheiden, bei der allen Besuchern beim ersten Aufrufen der Website eine eindeutige ID zugewiesen wird. Es ist egal, ob sie anonym oder authentifiziert sind. Wenn sich anonyme Benutzer registrieren, behalten Sie die eindeutige ID bei.

Speichern Sie den Einkaufswagen in der Datenbank. Speicher ist billig und es sollte kein Problem sein, hin und wieder eine Abfrage nach dem Warenkorb durchzuführen.

Beide Methoden haben Vor- und Nachteile, aber aus meiner Sicht hat der Datenbankspeicher zwei ziemlich große Vorteile.

1. Berichterstattung. Sie können keine Berichte zu aufgegebenen Warenkörben, Conversion-Raten usw. erstellen, wenn sich die Daten in der Sitzung befinden.
2. Sitzungs-Timeouts. Ich würde mich ärgern, wenn ich zum Abendessen gehen und feststellen würde, dass mein Wagen geleert wurde, weil die Sitzung abgelaufen ist. Ich könnte mir vorstellen, dass der Einzelhändler das auch nicht mag. Wir wollen den Benutzer zum Kaufen bewegen, nicht zum Aufgeben und Verlassen.

Die Frage geht davon aus, dass Sie überhaupt Sitzungen benötigen, die in meinem Kundenmarkt nicht benötigt werden. Zufällig betreibe ich mehrere hundert E-Commerce-Websites, von denen eine Handvoll hohen Datenverkehr aufweist. Wir verwenden keine Sitzungen, da sie nur skalierbar sind, wenn sie ausgefarmt sind, langsamer sind oder mehr Setup erfordern. Sitzungen verbrauchen Speicher und die Datenbank, die den Sitzungsstatus abruft, ist sehr langsam und erfordert mehr bewegliche Teile.

Stattdessen verwenden wir HTML5 sessionStorage, um alle Benutzerinformationen zu speichern, die wir immer wieder abrufen müssen, ohne dass jedes Mal ein Cookie-Rountrip erforderlich ist, um die Bandbreite zu erhöhen. Dies ist IE8 + und alle anderen modernen Browser und Mobilgeräte sind mit dieser Technologie kompatibel. ABER Sie können den Einkaufswagen einfach als Ersatz in einem Cookie ablegen, wie wir es zuvor getan haben. Hier ist ein guter Cookie-Cart: http://simplecartjs.org/

Wenn sich Benutzer anmelden oder einloggen, verwenden wir ein verschlüsseltes Cookie mit einem eingebrachten Zeitstempel.

Wir arbeiten auch an der Verwendung von ApplicationCache, um den Web-Datenverkehr als Randnotiz weiter zu reduzieren, da Sie Ressourcen und sogar Katalogdaten vorab abrufen können, sodass die Benutzerperspektive eine superschnell ladbare Website ist und Mobilgeräte auch offline funktionieren (abzüglich Transaktionen). Natürlich müssen Sie darauf achten, das Manifest zu aktualisieren, wenn sich Produkte usw. ändern.

Sie gehen davon aus, dass der Sitzungsspeicher und der Datenbankspeicher exklusiv sind. Sie sind nicht. Beginnen wir aber mit der Annahme, dass dies der Fall ist.

Der Vorteil der Sitzungsspeicherung ist dreifach:

1. Es müssen keine Daten explizit in die Datenbank eingefügt werden. Sie setzen einfach eine Sitzungsvariable und fertig. Einfach und funktional risikoarm.
2. Sie müssen den Lebenszyklus eines Besuchs durch den Benutzer und des Einkaufswagens nicht so verwalten, wie dies Container / Frameworks für Sie tun
3. Normalerweise wird die automatische Bereinigung alter inaktiver Sitzungen für Sie durchgeführt.

Nachteile des Sitzungsspeichers:

1. Sitzungsaffinität, es sei denn, Sie untersuchen die Replikation
2. Kein Failover, es sei denn, Sie untersuchen die Replikation oder die manuelle Speicherung des Sitzungsstatus auf der Festplatte, was zu Komplikationen führen kann.
3. Alle Sitzungen müssen gespeichert werden. Dies wird verstärkt, wenn Sie die Replikation verwenden.

Vorteile der Datenbankspeicherung:

1. Sie müssen sich keine Gedanken über Sitzungsaffinität oder Statusreplikation machen. Sie können alle Anfragen runderneuern.
2. Weniger Speicheraufwand in der Anwendung.
3. Wenn die Bestellung abgeschlossen ist, wird ohnehin alles in der Datenbank gespeichert, sodass die Fertigstellung möglicherweise vereinfacht wird, da die Daten bereits vorhanden sind.

Nachteile des Datenbankspeichers:

1. Verlassene Warenkörbe - Ein anonymer Benutzer hat einen Artikel in den Warenkorb gelegt und ist verschwunden. Diese Daten bleiben für immer erhalten, es sei denn, Sie haben einen Ablaufprozess.
2. Sie müssen eine Möglichkeit finden, Benutzer zu verfolgen und herauszufinden, ob es sich bei einer bestimmten Anforderung um eine vorhandene oder eine neue Browsersitzung handelt. (Ja, dies ist wahrscheinlich einfach, wenn Sie ein Cookie verwenden, aber wie stellen Sie sicher, dass zwei Benutzer nicht dieselbe ID haben?)
3. Mehr Code

Sie haben nicht erwähnt, welche Plattform Sie verwenden. Ich würde nach einem Ansatz suchen, der eine datenbankgestützte Sitzung verwendet, bei der die Sitzungsdaten nur während der Lebensdauer eines Anforderungs- / Antwortzyklus im Speicher vorhanden sind, sie aus der Datenbank laden und in die Datenbank zurückspeichern. Das hat mir in der Vergangenheit sehr geholfen.

Vorteile einer datenbankgestützten Sitzung:

1. Keine Notwendigkeit für Serveraffinität.
2. Schont den Speicher des App-Servers
3. Inaktive / abgebrochene Sitzungsdaten werden für Sie bereinigt.
4. Der Lebenszyklus des ersten Besuchs des Benutzers, des wiederholten Besuchs und des Sitzungsendes ist für Sie festgelegt.
5. Einfach zu codieren

Nachteile einer datenbankgestützten Sitzung:

1. Konfiguration - Sie müssen Ihren Container untersuchen, ob es sich um PHP, Java EE (Tomcat, Jetty, JBoss usw.), node.js + express.js oder etwas anderes handelt, das dies nicht unterstützt, und die richtige Konfiguration bereitstellen.
2. Möglicherweise müssen Sie dies testen, da Sie pro Anforderung 2 Datenbankvorgänge hinzufügen.

Es gibt eine dritte Möglichkeit, die jemand zuvor angesprochen hat. Sie können die Verwendung von Sitzungen insgesamt überspringen und clientseitigen Speicher verwenden, indem Sie entweder alles in ein Cookie oder in einen lokalen HTML-Speicher einbetten.

Ich überlasse Ihnen das Für und Wider als Übung, aber ich gebe Ihnen einen Hinweis, dass bei der Speicherung von HTML5 die Browserkompatibilität sorgfältig geprüft werden muss.

Ich habe die Fakten für Sie skizziert. Hoffentlich hilft Ihnen dies dabei, die richtige Entscheidung für Ihre Situation zu treffen.

Betrachten wir die beiden von Ihnen erwähnten Anwendungsfälle

Benutzer ist nicht angemeldet und legt ein Produkt in den Warenkorb (Anonymer Benutzer)

In diesem Fall möchten Sie auf jeden Fall die Warenkorbinformationen des Benutzers in einer Sitzung speichern, um dem Benutzer während seiner Sitzung einen guten Service zu bieten. Wenn er sich entscheidet, sich anzumelden oder ein Konto zu erstellen, können Sie dies basierend auf dem nächsten Anwendungsfall tun. Wenn er sich nicht anmeldet, müssen Sie Ihre Datenbank nicht mit den Informationen dieses Gastbenutzers füllen, da diese nur verwendet wurden, um den Gast während der Sitzung zu bedienen. Diese Daten können statusfrei verarbeitet werden, dh der Status wird nicht von Sitzung zu Sitzung gespeichert.

Der Benutzer ist angemeldet und legt ein Produkt in den Warenkorb.

In diesem Fall können Sie wie oben beschrieben vorgehen (alte E-Commerce-Websites) und diese Informationen auch zur Datenbank hinzufügen und dem Benutzer zuordnen. Dies wird hauptsächlich verwendet, um zustandsbezogene (von Sitzung zu Sitzung gespeicherte) Informationen bereitzustellen, wie z. B. "Produkt-Browserverlauf", "Empfehlungen" usw., ähnlich wie bei Amazon.com.

Dinge, über die man nachdenken sollte:

• Müssen Daten gespeichert werden?
• Wenn ja, welche Daten sind am kritischsten zu speichern, um dem Benutzer einen besseren Service zu bieten?
• Skalierbarkeit + Datenspeicherung - Wie werden die Warenkorbinformationen zur schnellen Suche in Ihrer Datenbank gespeichert, um viele Benutzer zu unterstützen?

Gehen Sie zur Sitzung, wenn der Benutzer nicht angemeldet ist. Auch wenn Sie angemeldet sind, erstellen Sie den Einkaufswagen zuerst in der Sitzung und speichern Sie ihn nur dann in der Datenbank, wenn sich der Benutzer abmeldet oder die Sitzung abläuft.

Sie müssen die Anzahl der in der Sitzung erstellten Warenkörbe überprüfen.