Warenkorb mit Sessions anstatt mit MySQL

[Andreas]

Hallo!

Ich habe gerade darüber nachgedacht, wie dumm ich war, meine Warenkörbe immer mit einer MySQL-Tabelle zu machen! Das einzige was ich da ja eintrage, ist die produktID und die Anzahl, dazu die sessionID. Aber das sind ja jedesmal ein paar unnötige Datenbank-Abfragen. Ich denke mit Sessions sollte das deutlich performanter sein, oder?
Jetzt frage ich mich nur, wie ich den Eintrag in die Session am einfachsten mache, denn mit der DB habe ich das immer so gemacht das ich auf der Produktseite einen Bestell-Link generiert habe, in In diesem wurde dann die übergebene produktID in die Warenkorb-Tabelle eingetragen, danach alle Datensätze der aktiven Session ausgelesen und angezeigt.
Bei Sessions ist das ja etwas anders, wenn ich in dem Warenkorb-Script entsprechend den Eintrag in der Session vornehme, wird der neue Artikel ja erst nach Ende des Scriptes in der Session gespeichert, also ist dieses Produkt beim direkten Auslesen noch nicht dabei.
Habt Ihr Erfahrungen wie ich das mit Sessions am besten mache?

2. Frage: Was ist noch sinnvoll in der Session zu speichern? Da jetzt ja nur die produktID in der Session steht, muß ich bei jedem Anzeigen(auf jeder Seite) die Datenbank erneut abfragen. Daher hatte ich auch schon dran gedacht, alle Daten zu einem Produkt in der Session zu speichern. Nur können das ein paar mehr Daten sein, ist das dann noch sinnvoll(schneller)? Muß ich dabei irgendwas beachten im Vergleich zur Speicherung in MySQL?

3. Frage: Ich hätte die Möglichkeit eine eigene php.ini zu benutzen, und so z.B. Sachen wie register_globals abschalten...
Dazu muß ich diese php.ini in dem Verzeichnis speichern, in dem das/die PHP-Scripte stehen, auf die die eigene php.ini angewendet werden soll. Keine Ahnung ob das standardmäßig so vorgesehen ist oder ein Feature des Providers, nur habe ich keine Ahnung ob durch sowas evtl. die Performance, die ich durch 'register_globals aus' und den Session-gestützten Warenkorb einspare, wieder verloren geht. hat da jemand Ahnung von?

Jedenfalls schonmal vielen Dank im voraus!

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas, melde mich auch wiedereinmal :-)

Ich habe gerade darüber nachgedacht, wie dumm ich war, meine Warenkörbe immer mit einer MySQL-Tabelle zu machen! Das einzige was ich da ja eintrage, ist die produktID und die Anzahl, dazu die sessionID. Aber das sind ja jedesmal ein paar unnötige Datenbank-Abfragen. Ich denke mit Sessions sollte das deutlich performanter sein, oder?

Performanter wahrscheinlich schon, wobei ich diese Lösung aus Gründen die folgen, nicht einschlägen würde.

2. Frage: Was ist noch sinnvoll in der Session zu speichern? Da jetzt ja nur die produktID in der Session steht, muß ich bei jedem Anzeigen(auf jeder Seite) die Datenbank erneut abfragen. Daher hatte ich auch schon dran gedacht, alle Daten zu einem Produkt in der Session zu speichern. Nur können das ein paar mehr Daten sein, ist das dann noch sinnvoll(schneller)?

Also die Session-Variante würde ich überhaupt nicht machen. Folgende Argumente sind (für mich!) ausschlaggebend:

1. Diese Lösung ist ganz einfach "sehr unschön" :-)
2. Nicht jeder unterstützt Cookies => Session am A...
3. Dann werden die Daten nicht mehr an einem Zentralen Ort gespeichert => einmal ist's in der Datenbank, das andere mal in der Session => unschön...
4. Dann kannst du als webmaster die einzelnen Einträge nicht mehr sehen; und ich zumindest will wissen, was auf meiner Page so abgeht :-)
5. eventuell musst du später einmal auf diese Cart - Daten zurückgreifen um z. B. Statistiken/History-Funktionen zu implementieren; über Sessions könntest du das nicht.
6. Wenn ich schon was mit mysql programmiere, will ich dort auch _alles_ haben. Der Übersicht zu liebe.
7. Ich mag's einfach, wenn alles mit mysql geschieht (ist wohl unschwer zu verkennen) :-)

Viele Grüsse

Philipp

[Andreas]

Hallöchen!

Halihallo Andreas, melde mich auch wiedereinmal :-)

jaja, Antwort kommt ;-)

Performanter wahrscheinlich schon, wobei ich diese Lösung aus Gründen die folgen, nicht einschlägen würde.

Mal gucken welche ich davon widerlegen kann ;-)))

Also die Session-Variante würde ich überhaupt nicht machen. Folgende Argumente sind (für mich!) ausschlaggebend:

1. Diese Lösung ist ganz einfach "sehr unschön" :-)

was ist das für ein Argument? Was ist an einer DB schöner?

2. Nicht jeder unterstützt Cookies => Session am A...

Ich habe Session-Cookies kpl.(komplett ;-)))) abgeschaltet, das geht alles über die URL, keine Cookies! Außerdem bräuchte ich die Session eh, um den User wiederzuerkennen, ohne Funktioniert kein Warenkorb!!! Und Session Cookies werden im Gegensatz zu "normalen" Cookies fast immer automatisch akzeptiert!

3. Dann werden die Daten nicht mehr an einem Zentralen Ort gespeichert => einmal ist's in der Datenbank, das andere mal in der Session => unschön...

Die Warenkortbdaten sind doch nur temporär! Die brauche ich eh nie wieder, bzw. habe die in der DB am nächsten Tag immer alle gelöscht! Die produkte stehen in der DB, die BEstellungen auch... den Resct brauche ich eh nicht! Da kommt mir auch dei Warenkorb-Klasse wieder in den Sinn, das würde ja auch funktionieren, mit dem Nachteil das die Variable erst _nach_ Ausführen eines Scriptes gespeichert werden, mal gucken wie das dann mit der Klasse funktioniert!

4. Dann kannst du als webmaster die einzelnen Einträge nicht mehr sehen; und ich zumindest will wissen, was auf meiner Page so abgeht :-)

Hm, das ist dcoh nun wirklich Datenmüll, was die Leute in den Warenkorb legen, ohne fundiertes Wissen(nicht falsch verstehen ;-)) bringt dir das eh nicht viel!

5. eventuell musst du später einmal auf diese Cart - Daten zurückgreifen um z. B. Statistiken/History-Funktionen zu implementieren; über Sessions könntest du das nicht.

Über die DB auch nicht, wenn ich die Einträge regelmäßig lösche. Ich denke der Warenkorb alleine ist nicht gerade aussagekräftig, und alle Daten die Du da sammelst kann man auch an anderer Stelle sammeln!

6. Wenn ich schon was mit mysql programmiere, will ich dort auch _alles_ haben. Der Übersicht zu liebe.

Warum benutzt Du dann überhaupt Perl, und läßt die Leute keinen MySQl Client runterladen und die Daten direkt eintragen? *kleiner Scherz* Man muß ja immer sehen, welche Technik wofür besser geeignet ist, und welche schlechter!

7. Ich mag's einfach, wenn alles mit mysql geschieht (ist wohl unschwer zu verkennen) :-)

Ja, aber zu Lasten der Performance, nur weil Du die DB so "magst"? Bei Dir scheint das Programmieren ja ne richtig sentimentale, ja fast romantische Sache zu sein ;-)

Ich glaube Du weiß nicht, wie einfach und unkompliziert der Umgang mit Sessions in PHP ist ;-))))))

Viele Grüße
Andreas

[Mike Roth]

Hi Andreas,

Die Warenkortbdaten sind doch nur temporär! Die brauche ich eh nie wieder, bzw. habe die in der DB am nächsten Tag immer alle gelöscht! Die produkte stehen in der DB, die BEstellungen auch...

Ich bin Programmierer, aber zu meiner Schande muß ich gestehen, daß
ich wenig Ahnung habe von Perl, MySql ( von SQL schon ) und von PHP.

Aber, aus meiner Programmierer Sicht würde ich auch mal behaupten,
daß die Daten im Warenkorb temporär und deshalb auch Datenmüll
sind.

Gruß
Mike

[Philipp Hasenfratz]

Halihallo again

Performanter wahrscheinlich schon, wobei ich diese Lösung aus Gründen die folgen, nicht einschlägen würde.
Mal gucken welche ich davon widerlegen kann ;-)))

... und welche ich re-wiederlegen kann :-))

Also die Session-Variante würde ich überhaupt nicht machen. Folgende Argumente sind (für mich!) ausschlaggebend:

1. Diese Lösung ist ganz einfach "sehr unschön" :-)
   was ist das für ein Argument? Was ist an einer DB schöner?

RDBMS eben :-)
SQL, Sockets, Datawarehousing, Integrität :-)
OK. Zugegeben, das Argument ist schwach, aber ich mag keine Sessions :-)
Ist mir zu Client-bezogen... Ich mags, wenn alles auf'm Server passiert. Dann hab ich alles unter Kontrolle und überlasse nix dem Zufall... :-)

2. Nicht jeder unterstützt Cookies => Session am A...
   Ich habe Session-Cookies kpl.(komplett ;-)))) abgeschaltet, das geht alles über die URL, keine Cookies! Außerdem bräuchte ich die Session eh, um den User wiederzuerkennen, ohne Funktioniert kein Warenkorb!!!

OK; das ist wahr. Sonst bräuchtest du einen Login...

Und Session Cookies werden im Gegensatz zu "normalen" Cookies fast immer automatisch akzeptiert!

Was ist denn der Unterschied? - Woran erkennt das der Browser?

3. Dann werden die Daten nicht mehr an einem Zentralen Ort gespeichert => einmal ist's in der Datenbank, das andere mal in der Session => unschön...

Die Warenkortbdaten sind doch nur temporär! Die brauche ich eh nie wieder, bzw. habe die in der DB am nächsten Tag immer alle gelöscht!

Ach so. Entschuldige, das hab ich nicht mitgekriegt; dann fallen in der Tat einige meiner Argumente ins Bodenlose :-)

Die produkte stehen in der DB, die BEstellungen auch... den Resct brauche ich eh nicht! Da kommt mir auch dei Warenkorb-Klasse wieder in den Sinn, das würde ja auch funktionieren, mit dem Nachteil das die Variable erst _nach_ Ausführen eines Scriptes gespeichert werden, mal gucken wie das dann mit der Klasse funktioniert!

Wenn das Script doch die Session aktualisiert, hast du ja auch die Daten irgendwo im RAM-Speicher. D. h. du müsstest diese einfach vom entsprechenden Ort (z. B. Forumlardaten) holen und nicht von der Session. Oder eben auch wieder ein Vorteil von RDBMS: Die Daten werden "real-time" verändert und müssen nicht zum nächsten Scriptaufruf warten...

6. Wenn ich schon was mit mysql programmiere, will ich dort auch _alles_ haben. Der Übersicht zu liebe.
   Warum benutzt Du dann überhaupt Perl, und läßt die Leute keinen MySQl Client runterladen und die Daten direkt eintragen? *kleiner Scherz* Man muß ja immer sehen, welche Technik wofür besser geeignet ist, und welche schlechter!

Meine "Leute" verstehen nix von mysql und SSH, deshalb! :-)))
OK. Hast schon recht.

7. Ich mag's einfach, wenn alles mit mysql geschieht (ist wohl unschwer zu verkennen) :-)
   Ja, aber zu Lasten der Performance, nur weil Du die DB so "magst"? Bei Dir scheint das Programmieren ja ne richtig sentimentale, ja fast romantische Sache zu sein ;-)

hehe :-)
Wenn man sie sonst nirgends an den Mann oder bessergesagt Frau bringen kann ;-))
Aber ja, in den Jahren hab ich schon ne gewisse Zuneigung zum Programmieren bekommen (von den unzähligen Fehlern mal abgesehen) :-)

Ich glaube Du weiß nicht, wie einfach und unkompliziert der Umgang mit Sessions in PHP ist ;-))))))

Anscheinend :-)))

OK. Nun hast du mich ja in Grund und Boden argumentiert und mir keine Chance gegeben. Na gut, so sei's dir gegönnt, dann helf ich dir eben bei deiner Umsetzung :-)))

Ich les nochmals kurz dein Ausgangsposting durch, lass mir was 'gscheites einfallen und meld mich dann wieder.

Viele Grüsse

Philipp

[Michael Schröpl]

Hi Philipp,

Außerdem bräuchte ich die Session eh, um den User
wiederzuerkennen, ohne Funktioniert kein
Warenkorb!!!
OK; das ist wahr. Sonst bräuchtest du einen Login...

Authentifizierung alleineersetzt noch keine Session.

Ein Benutzer kann sich unter derselben Benutzerkennung
mehrfach parallel einloggen; eine Session muß das ver-
hindern, braucht also ein dynamisches Gedächtnis, was
die reine Authentifizierung nicht braucht

Und Session Cookies werden im Gegensatz zu
"normalen" Cookies fast immer automatisch
akzeptiert!
Was ist denn der Unterschied? - Woran erkennt das
der Browser?

Es gibt Cookies, deren Lebensdauer auf die Browser-
Sitzung beschränkt ist, und solche, die bis zu einem
angegebenen Datum gespeichern bleiben sollen.

Überhaupt sehe ich gar keinen Widerspruch zwischen
Sessions und Datenbank.
Denn wie willst Du in der Datenbank die Informationen
des aktuellen Kommunikations-Strangs (HTTP besteht ja
aus getrennten zugriffen) als zusammengehörig erkennen,
außer durch eine Session-Logik?

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Andreas]

Moin!

Halihallo again

Haui-Fan?

... und welche ich re-wiederlegen kann :-))

tja...

RDBMS eben :-)
SQL, Sockets, Datawarehousing, Integrität :-)
OK. Zugegeben, das Argument ist schwach, aber ich mag keine Sessions :-)

Wieso nicht? Sag mal bitte, was Dich an Sessions stört!

Ist mir zu Client-bezogen... Ich mags, wenn alles auf'm Server passiert. Dann hab ich alles unter Kontrolle und überlasse nix dem Zufall... :-)

Hä? Was  ist daran mehr Client-bezogen, als an einer Session/MySQL Lösung?
Wie gesagt brauche ich Sessions auf alle Fälle. Dir ist auch klar, das die Sessiondaten auf dem Server gespeichert werden, noch nichtmal ein Cookie wird beim Client gespeichert, die SessionID wird immer per GET/POST über den gesamten Shop als Variable "mitgeschleppt"! Der Cient Sesdet auslo immer die SessionID ine seinem HTTP-Request ebntweder im GET oder POST Header mit, sonst nichts, und nur die ID, der Rest(die eigentlichen Daten, auch komplette Arrays!) wird in Sessiondateien auf dem Server abgelegt. Wie gesagt, noch nichtmal Cookies werden verwendent!

OK; das ist wahr. Sonst bräuchtest du einen Login...

Selbst mit Login bräuchte ich Sesions(oder eigenen Wiedererkennungs-algorythmus, oder .htaccess), aber dazu hat Michael sich ja schon geäußert!

Was ist denn der Unterschied? - Woran erkennt das der Browser?

Sie Michael, und guck mal in den Sicherheitseinstellungen(oder Datenschutz) Deines Browsers, beim IE z.B. gibt es Cookies von 2. und 3.-Anbieter, und Sitzungscookies, die werden je nach Einstellung unterschiedlich behandelt, den Sitzungscookies wird standardmäßig immer am meisten vertraut!

Ach so. Entschuldige, das hab ich nicht mitgekriegt; dann fallen in der Tat einige meiner Argumente ins Bodenlose :-)

... tja ;-) Nur ernsthaft, überleg Dir malö, wieviele Daten unnütz im Warenkorb liegen, und erklär mir doch mal, was Du bis heute daraus für Schlüsse ziehen konntest!

Wenn das Script doch die Session aktualisiert, hast du ja auch die Daten irgendwo im RAM-Speicher. D. h. du müsstest diese einfach vom entsprechenden Ort (z. B. Forumlardaten) holen und nicht von der Session. Oder eben auch wieder ein Vorteil von RDBMS: Die Daten werden "real-time" verändert und müssen nicht zum nächsten Scriptaufruf warten...

Ja, ich habe die Daten ja am Anfang des Sriptes, jetzt ist dei Frage, was sauberer ist, noch ein Script dazwischen hängen("Artikel XY wurde in Warenkorb gelegt..."), hier in der Session registrieren, und dann per headerweiterleitung auf den Warenkorb hat man dann alle Daten. Die 2. Möglichkeit wäre, die bisherigen Daten in der Session uind die aktuellen Datzen aus dem Formula direkt anzuzeigen, nur wenn man dann einen Artikel löschen will, oder die Anzahl ändern, dann wirds kompliziert, ode? Wir sieht es Deiner meinung nach mit der Warenkob Klasse aus, kann man die noch kompatibel zu einer DB halten?

Ich glaube Du weiß nicht, wie einfach und unkompliziert der Umgang mit Sessions in PHP ist ;-))))))

Anscheinend :-)))

Du kannst in PHP in jedem Script mit

session_start();

Die Sesion aktivieren, wenn noch neu, dann wird diese neu angelegt, sonst hast Du direkten Zugriff auf alle Variablen in der Session, mit einem

$_SESSION[$warenkorb_array];

würdest Du z.B. einen kopl. Array Warenkorb in de Session abspeichern oder aktualisieren, Du kannst so viele Arrays und Variablemn in dem Session-Array speichern, wie Du willst! Das ist doch nun wirklich einfach, oder?  Auf der nächsten Seite hättest Du sogar Zugriff auf den Warenkorb mit

session_start();
$warenkorb_array;

Was aber langfristig aus Seicherheits und performance Gründen vemieden werden sollte, also lieber mit

session_start();
$_SESSION[$warenkorb_array];

Ist doch wirklich nicht so unschön, oder?

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo nochmals

OK, du Argumentator, mal sehen wie dir das gefällt: :-)))

Bei Sessions ist das ja etwas anders, wenn ich in dem Warenkorb-Script entsprechend den Eintrag in der Session vornehme, wird der neue Artikel ja erst nach Ende des Scriptes in der Session gespeichert, also ist dieses Produkt beim direkten Auslesen noch nicht dabei.

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:

name1=value1
name2=value2

also genauso, wie die Daten in der Session gespeichert sind (name-value-Paare). Selbstverständlich hält dich keiner davon ab auch ein XML-File mit den Daten zu erstellen (aber das wird die Performance dann wirklich etwas beeinträchtigen) :-)

Habt Ihr Erfahrungen wie ich das mit Sessions am besten mache?

Nein!!! :-))))))

2. Frage: Was ist noch sinnvoll in der Session zu speichern?

Nein!!! :-))))))

Da jetzt ja nur die produktID in der Session steht, muß ich bei jedem Anzeigen(auf jeder Seite) die Datenbank erneut abfragen. Daher hatte ich auch schon dran gedacht, alle Daten zu einem Produkt in der Session zu speichern. Nur können das ein paar mehr Daten sein, ist das dann noch sinnvoll(schneller)?

Es hält dich niemand davon ab die ganze Datenbank in die Session zu spiegeln [sorry für diese alberne Anspielung, aber es hat mich grad so schön gereizt] :-))))

Also: Wenn du schon so performant sein willst: Es wäre unklug alle Produktdaten, welche im Warenkorb referenziert sind in die gleiche Session zu speichern; da dann mehrere Kunden über die genau gleichen Daten in der Session verfügen ( => Redundanz ). Wenn du die vorher genannte Lösung mit den .txt Dateien nimmst, könntest du das folgendermassen machen:

productID=15
count=27
...

wobei du in einem Verzeichnis /products
eine Datei 15.txt liegen hast, welche die Produktdaten enthält. Falls dann ein anderer Kunde dasselbe Produkt im Warenkorb hat, greifen beide auf dieselbe Datei zurück => Redundanz OK. Hier dürfte nur ein kleines Problem mit dem Datenabgleich aufkommen. Wenn ein Produkt-Record in der DB verändert wird, muss auch die entsprechende .txt Datei aktualisiert werden.

Viele Grüsse

Philipp

PS: Das Unperformante an einer Datenbank ist der Verbindungsaufbau, nicht die Query-Abfrage. Wenn du eine Verbindung im Progi offen hast, die sowieso gebraucht wird, ist der Performanceverlust wohl vorhanden, aber eher klein...

[Sven Rautenberg]

Moin!

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: Für jede eröffnete Session wird eine Textdatei angelegt, welche die Daten der Session (also alle registrierten Session-Variablen) enthält. Hat nur den Vorteil, daß man die ganze Dateiverwaltungsscheiße einfach PHP überläßt, wie z.B. gleichzeitige Dateizugriffe zu verhindern etc.

Mit anderen Worten: Deine Lösung kann eigentlich nur unperformanter sein, als PHP einfach die Verwaltung zu überlassen. Denn um die Variablen aus der Textdatei auszulesen und dem Script zur Verfügung zu stellen, muß natürlich PHP-Code eingelesen, kompiliert und ausgeführt werden - wie optimiert der dann ist, ist die Frage. Optimaler als die Routinen in PHP selbst wird das aber wohl kaum sein.

Also keine so besonders gute Idee.

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. :)

- Sven Rautenberg

[Philipp Hasenfratz]

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

[Sven Rautenberg]

Yo!

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...

Das ist ein Denk- oder Umsetzungsfehler bei den Sessions. Meine Erfahrungen sind da etwas anders.

Wenn in der Session bereits Daten gespeichert sind, werden diese in die entsprechenden Variablen übertragen, sobald im Skript start_session() aufgerufen wird. Ab da hat man also die von der letzten Seite hinübergeretteten Werte verfügbar und kann mit den Variablen arbeiten.

Wenn die Bearbeitung erfordert, weitere Daten zu speichern, wird man diese Daten sinnvollerweise in die Variable tun.

Weiterer Output für den Besucher (also die erneute, jetzt ergänzte Ausgabe des Warenkorbinhaltes) wird man sinnvollerweise basierend auf der Variablen generieren.

Endet das Skript, dann wird der aktuelle Zustand der Variablen wieder gespeichert. Fertig.

Insofern ist die Session-Lösung einer Datenbanklösung absolut gleichwertig, jedenfalls vom Datenhandling und ihrer Verfügbarkeit.

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?

Warum nicht gleich diese Hashvariable als Sessionvariable festlegen? :)

- Sven Rautenberg

[Andreas]

Moin, Moin!

Das ist ein Denk- oder Umsetzungsfehler bei den Sessions. Meine Erfahrungen sind da etwas anders.

Naja, wie ich das mit der DB gemacht habe, habe ich bereits geschrieben, also auf der Produktseite habe ich einen Link wie "warenkorb.php?produktID=123", am Anfang des Scriptes warenkorb.php kommt denn ein

"INSERT INTO
  warenkorb
  (produktID,Anzahl,PHPSESSID)
 VALUES
  ('$produktID','$anzahl','$PHPSESSID')";

und danach ein

"SELECT * FROM
  warenkorb
 WHERE
  PHPSESSID = '$PHPSESSID'";

Jetzt werden diese Daten alle angezeigt. Jetzt sag mir mal wie Du das genau so mit Sessions machst? Wenn ich anstatt der ersten Sache schreibe

$warenkorb_array[$produktID]=$anzahl;
$_SESSION[$warenkorb_array];

oh - Du hast Recht! In $warenkorb_array steht ja jetzt schon alles ;-))) Prima! Wie bin ich da wohl drauf gekommen?

Wenn in der Session bereits Daten gespeichert sind, werden diese in die entsprechenden Variablen übertragen, sobald im Skript start_session() aufgerufen wird. Ab da hat man also die von der letzten Seite hinübergeretteten Werte verfügbar und kann mit den Variablen arbeiten.

Mein Problem war, das ich auf ein und derselben Seite die Variable registrieren und auslesen wollte, aber hat sich ja erledigt ;-)

Wenn die Bearbeitung erfordert, weitere Daten zu speichern, wird man diese Daten sinnvollerweise in die Variable tun.

Ja mit Arrays habe ich das noch nie gemacht, werde es aber rein Interesse halber mal probieren!

Weiterer Output für den Besucher (also die erneute, jetzt ergänzte Ausgabe des Warenkorbinhaltes) wird man sinnvollerweise basierend auf der Variablen generieren.

Wie meinst Du das? Ich speicher so wie oben ja nur die produktID als key, und die Anzahl als value im warenkorb-array, ist jetzt die Frage ob das reicht, und so bei jeder Ausgabe die restlichen Daten(Preis, Bezeichnung...) aus der DB ausgelesen werden müssen, oder ob man nicht nur die produktID und Anzahl speichert, sondern einen eigenen Array für jeden Artikel im warenkorb_array, und darin alles notwendige speichert und so immer ausgeben kann, ohne sich mit der DB zu verbinden. Was meinst Du dazu?

Endet das Skript, dann wird der aktuelle Zustand der Variablen wieder gespeichert. Fertig.

Genau, aber erst dann, wenn ich die Ausgabe vorher will geht das ja nicht, aber da ich die Variable ja speichere, kann ich ja ohne auf die Session zuzugreifen den aktuellen 'Wert' des Arrays auslesen.

Insofern ist die Session-Lösung einer Datenbanklösung absolut gleichwertig, jedenfalls vom Datenhandling und ihrer Verfügbarkeit.

Das habe ich jetzt auch verstanden.

Warum nicht gleich diese Hashvariable als Sessionvariable festlegen? :)

Das wäre auch mein Vorschlag. Nur um das nochmal klarzustellen:
Ich bin nicht dabei, ein Performance-Problem zu beheben, sondern einen sträflich geschrieben Anfänger-Warenkorb (mein erstes richtiges PHP-Script ;-)) neu zu schreiben. Und jetzt habe ich halt die Qual der Wahl, und würde mich jetzt gerne direkt für die bessere Lösung entscheiden, bevor ich dann im Fall der Fälle nochmal was ändern müßte. Ich glaube Du hast Recht, ich werde wohl auch langfristig keine derartigen Performance-Probleme bekommen. Also lassen wir mal den Performance-Gesichtspunkt außern vor. Der einzige Vorteil ist ja noch, das evtl. erst gar keine Verbindung zur DB aufgenommen werden muß, aber 1. habe ich eh eine persistente Verbindung(die bleibt doch über ein Script hinaus bestehen oder?), und 2. greife ich eh auf den meisten Seite zusätzlich auf die DB zurück, also ist diese zeitliche Verzögerung auch zu vernachlässigen. Aber ein anderer Vorteil wäre, ich könnte mal mehr über Sessions und Arrays lernen, was ja auch nicht schlecht wäre, aber da hat der Warenkorb nichts von ;-)
Welche Varinate würdet Ihr jetzt noch empfehlen? Auch in anbetracht der Tatsache, das ich gerne mal mit einer Warenkorb-Klasse arbeiten würde!

Vielen Dank schonmal und viele Grüße

Andreas

[Sven Rautenberg]

Yo!

Weiterer Output für den Besucher (also die erneute, jetzt ergänzte Ausgabe des Warenkorbinhaltes) wird man sinnvollerweise basierend auf der Variablen generieren.
Wie meinst Du das?

Hole Warenkorb der Session (mit session_start()).

• Ergänze Warenkorb um die jetzt abgeschickte Bestellung.
  = aktueller Warenkorb ist gespeichert.

Wenn jetzt der Warenkorb ausgegeben werden soll, schreibst du den Inhalt der Warenkorbvariablen auf den Bildschirm. Genauso, wie du vorher SELECT * FROM tabelle WHERE Sessionid gemacht hast.

Ich speicher so wie oben ja nur die produktID als key, und die Anzahl als value im warenkorb-array, ist jetzt die Frage ob das reicht, und so bei jeder Ausgabe die restlichen Daten(Preis, Bezeichnung...) aus der DB ausgelesen werden müssen, oder ob man nicht nur die produktID und Anzahl speichert, sondern einen eigenen Array für jeden Artikel im warenkorb_array, und darin alles notwendige speichert und so immer ausgeben kann, ohne sich mit der DB zu verbinden. Was meinst Du dazu?

Wozu sonst wäre die Umstellung auf die Sessions gut? Ziel war doch, weniger mit der Datenbank zu arbeiten. Wenn du aber nur rudimentäre Daten in der Session hälst und im Zweifel immer wieder die Datenbank befragen mußt, was der Warenkorb in menschlichen Worten bedeutet, dann ist nicht viel gewonnen.

Allerdings soll's ja angeblich ein Datenmaximum für Sessiondaten geben. Ich kann dazu nicht viel sagen, ich habe nichts gegen ein ständiges Befragen und Befüllen der Datenbank einzuwenden - und somit dein Problem nicht. :)

Endet das Skript, dann wird der aktuelle Zustand der Variablen wieder gespeichert. Fertig.
Genau, aber erst dann, wenn ich die Ausgabe vorher will geht das ja nicht, aber da ich die Variable ja speichere, kann ich ja ohne auf die Session zuzugreifen den aktuellen 'Wert' des Arrays auslesen.

Häh? Du hast eine in der Session gespeicherte Variable. Die steht am Anfang des Skriptes zur Verfügung. Du schreibst weitere Werte in die Variable hinein. Du liest die komplette Variable für eine Ausgabe aus. Und durch das Skriptende wird der (geänderte) Inhalt der Variablen zum nächsten Skript hinübergerettet. Wo ist da das Problem?

Wenn du natürlich lesens über $_SESSION zugreifst, dann solltest du auch schreibend dort die Veränderung vornehmen. Wenn das nicht möglich ist, weil du komplexe Variablen so nicht ansprechen kannst, dann nimm doch lieber die Originalvariable und überlasse das Rauspfriemeln und Abspeichern in der Session PHP. :)

- Sven Rautenberg

[Andreas]

Hallo!

Wozu sonst wäre die Umstellung auf die Sessions gut? Ziel war doch, weniger mit der Datenbank zu arbeiten. Wenn du aber nur rudimentäre Daten in der Session hälst und im Zweifel immer wieder die Datenbank befragen mußt, was der Warenkorb in menschlichen Worten bedeutet, dann ist nicht viel gewonnen.

Das stimmt.

Allerdings soll's ja angeblich ein Datenmaximum für Sessiondaten geben. Ich kann dazu nicht viel sagen, ich habe nichts gegen ein ständiges Befragen und Befüllen der Datenbank einzuwenden - und somit dein Problem nicht. :)

Mit anderen Worten gewinnde ich Durch einen Session-Warenkorb nicht viel. oder? Außerdem müßte ich beim Eintragen auch die Daten erst aus der DB auslesen und in die Session schreiben, was schlechter ist als ein enfacher insert!

Häh? Du hast eine in der Session gespeicherte Variable. Die steht am Anfang des Skriptes zur Verfügung. Du schreibst weitere Werte in die Variable hinein. Du liest die komplette Variable für eine Ausgabe aus. Und durch das Skriptende wird der (geänderte) Inhalt der Variablen zum nächsten Skript hinübergerettet. Wo ist da das Problem?

Jajaja, hatte ich inzwischen verstanden ;-) Denkfehler von mir!

Wenn du natürlich lesens über $_SESSION zugreifst, dann solltest du auch schreibend dort die Veränderung vornehmen. Wenn das nicht möglich ist, weil du komplexe Variablen so nicht ansprechen kannst, dann nimm doch lieber die Originalvariable und überlasse das Rauspfriemeln und Abspeichern in der Session PHP. :)

Naja, da langfristig in PHP register globals ja auf off geschaltet wird, was aus Sicherheitstechnischen und performanten Gesichtspunkten zu befürworten ist(auch für langfristige Kompatibilität), stehen Sessionvariablen ja nicht mehr direkt zur Verfügung! Also muß ich duch $_SESSION darauf zugreifen, auch in Anbetracht der Tatsache, das langfristig $HTTP_SESSION_VARS abgeschaltet wird, wahrscheinlich mit PHP 5.

Also bräuchte ich auf jeder Seite

<?
session_start();
$warenkorb = $_SESSION[$warenkorb_array];
$_SESSION[$warenkorb_array] = $warenkorb;
?>

oder?

Aber alles in allem haben sich glaube ich die Vorteile des Sesion-Warenkorbes eh in Wohlgefallen aufgelöst ;-)

Wollte das nur mal ansprechen, um zu sehen, ob die MySQL-Warenkorb Lösung auch wirklich die beste ist!

Vielen Dank jedenfalls!

Grüße
Andreas

[Andreas]

Hallöchen!

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.

Wie Du unten lesen kannst, hat sich as erledigt, sorry für die Fehlinformation ;-)

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:

name1=value1
name2=value2

Das könnte ich mit einem warenkorb-array machen, den ich einfach in der Session speichern kann!

Also: Wenn du schon so performant sein willst: Es wäre unklug alle Produktdaten, welche im Warenkorb referenziert sind in die gleiche Session zu speichern; da dann mehrere Kunden über die genau gleichen Daten in der Session verfügen ( => Redundanz ). Wenn du die vorher genannte Lösung mit den .txt Dateien nimmst, könntest du das folgendermassen machen:

productID=15
count=27
...

wobei du in einem Verzeichnis /products
eine Datei 15.txt liegen hast, welche die Produktdaten enthält. Falls dann ein anderer Kunde dasselbe Produkt im Warenkorb hat, greifen beide auf dieselbe Datei zurück => Redundanz OK. Hier dürfte nur ein kleines Problem mit dem Datenabgleich aufkommen. Wenn ein Produkt-Record in der DB verändert wird, muss auch die entsprechende .txt Datei aktualisiert werden.

Naja, aber das müßte alles gepflegt werden... finde ich sehr unschön, da könnte ich ja auch auf die DB verzichten, und Probleme mit der Performance werd eich mit der DB auch nicht haben. Nur da der Warenkorb so viele Temporäre Daten und voiele Zugriffe enthält, dachte ich mir hierfür wäre evtl eine andere Art der Datenhaltung besser! Außerdem kommt es mit großer Sicheheit zu keinen Überschneidungen, da im Online-Shop eine 5-Stellige Anzahl an Artikeln liegt, wo nicht wiorklich wahrscheinlich ist, das Leute gleichzeitig denselben Artikel im Warenkorb haben, und unter dem Gesichtspunkt wäre das eine ganze Menge Arbeit für nichts und wieder nichts, auch noch unperformanter als alles in einem Session-Array zu speichern!

PS: Das Unperformante an einer Datenbank ist der Verbindungsaufbau, nicht die Query-Abfrage. Wenn du eine Verbindung im Progi offen hast, die sowieso gebraucht wird, ist der Performanceverlust wohl vorhanden, aber eher klein...

Das stimmt, die Performance ist daher auch kein Problem, nur wollte ich die best mögliche Performance bei der Neuentwicklung des Warenkorbs!

Vielen Dank udn schöne Grüße

Andreas