Philipp Hasenfratz: Warenkorb mit Sessions anstatt mit MySQL

Beitrag lesen

Halihallo Sven

Was spricht gegen die Lösung, dass die Daten nicht in der Session, sondern in einer .txt Datei gespeichert werden und nur durch die Session "referenziert" wird? - Das wird an der Performance wenig ändern (wahrscheinlich macht das PHP sogar genauso), hätte aber folgenden Vorteil:

Die Daten sind jederzeit gleich "real-time", wie in der DB-Solution. Auch wenn du später mal den Warenkorbinhalt inspizieren möchtest (eventuell...), hättest du die Möglichkeit dazu. Das Warenkorb-Modul hätte auch im gleichen Script noch die Möglichkeit (ohne programmiertechnische Tricks) die Daten einzulesen.

Also, für jede neue Session/Besucher erstellst du einen eindeutigen Dateinamen (1.txt, 2.txt, ...), welcher die "Sessiondaten" bzw. die Warenkorb- und Produktdaten enthält. Die .txt - Datei hat folgendes, simples, aussehen:

Tja, PHP macht das in der Tat genauso:

das hab ich mir gedacht ;-)

Mit anderen Worten: Deine Lösung kann eigentlich nur unperformanter sein

Klar.

Also keine so besonders gute Idee.

doch, doch ;-)
Ich dachte mir schon, dass PHP genau das (nur eben schneller) macht, was ich vorschlage; aber: Andreas sagte, dass die Daten erst beim _nächsten_ Programmstart wieder einlesbar sind (keine Ahnung warum??? - Session wird nur am Beginn eingelesen und nachher nicht mehr aktualisiert???). Deshalb schlug ich die Variante vor, dass man die Daten eben selber aufbewahrt und somit immer den aktuellen Stand in der Datei hat, sodass er auch im selben Programm noch auf die gespeicherten Daten zugreifen kann...
Hast mich grad noch auf eine andere Lösung gebracht:
Wenn schon die Performance gut sein soll: Warum nicht am Anfang eines jeden Programmes den Datenbestand der Session in ein assoz. Array spiegeln, dann _nur_ dieses Verwenden (dann hat man immer die aktuellen Daten, auch wenn diese geändert wurden), und am Schluss des Programmes die ganzen Daten aus dem Array wieder in die Session schreiben?

Spannend auch die Frage: Hier wird immer von Performance geredet. Dabei kann ich mir kaum vorstellen, daß immer ein Performanceproblem vorliegt. Wenn's um Performance geht, dann stellt man das eigentlich daran fest, daß ein gewisser Vorgang unerträglich lange dauert. Dann sollte man Optimierungen vornehmen - das kann von besserem Code über andere Verfahrensweisen bis hin zu schnellerer Hardware gehen. Die Frage ist zuerst, was sich am leichtesten realisieren läßt. Und dann, was am billigsten machbar ist. Und hinterher muß natürlich getestet werden, ob es wirklich performanter ist. :)

Ja, da hast du recht ;)

Viele Grüsse

Philipp