nicht angemeldet
Warenkorb in Cookie oder in Datenbank
Hallo Leute,
ich möchte gerne eine Art Warenkorb programmieren, nun ist die Frage, ob ich die Daten (ArtikelNr,Anzahl) als Cookie speicher, oder eine weitere Tabelle in der Datenbank anlege...
Als Cookie hat meiner Meinung nach den Vorteil, dass a) weniger Platz auf dem Server verbraucht wird ;-), b) ich keinen Datenmüll in der Datenbank habe (, denn was ist mit den Daten, die die Leute zwar in dem Warenkorb haben, aber nur einmal auf der Seite waren? evtl. eine weitere spalte mit nem Datum, das die Artikel nach n-Tagen wieder gelöscht werden?)
Die weitere Tabelle hätte den Vorteil, dass das zugreifen, löschen, ändern, wesentlich leichter ist...
Was meint Ihr denn?
Vielen Dank für Eure Hilfe!
mfg
Der Schröder
-
Hi,
Als Cookie hat meiner Meinung nach den Vorteil, dass a) weniger Platz auf dem Server verbraucht wird ;-),
also, wenn _das_ für Dich bedenklich wird, hast Du auch genügend Bestellungen, um Dir mehr Webspace leisten zu können ;-)
Bedenke vor allem, dass Cookies nicht nur in der Menge pro Host begrenzt sind, sondern auch in der jeweiligen Länge, und dass viele User Cookies nicht gerne sehen und ablehnen - und sogar entsprechende Sites umgehend verlassen.
b) ich keinen Datenmüll in der Datenbank habe (, denn was ist mit den Daten, die die Leute zwar in dem Warenkorb haben, aber nur einmal auf der Seite waren? evtl. eine weitere spalte mit nem Datum, das die Artikel nach n-Tagen wieder gelöscht werden?)
Du müsstest zum Zwecke der User-Erkennung ohnehin einen Session-Mechanismus implementieren. Dieser sollte auch über Carbage-Collection-Routinen verfügen: alle Daten abgelaufener Sessions werden gelöscht. Bei einem hinreichend mächtigen DBMS ist dies durch ein ON DELETE CASCADE in der Foreign-Key-Definition problemlos machbar.
Die weitere Tabelle hätte den Vorteil, dass das zugreifen, löschen, ändern, wesentlich leichter ist...
Ich empfehle einen serverseitigen Mechanismus. Auf den Client kann man sich _nie_ verlassen.
Cheatah
-
Hi,
Als Cookie hat meiner Meinung nach den Vorteil, dass a) weniger Platz auf dem Server verbraucht wird ;-),
also, wenn _das_ für Dich bedenklich wird, hast Du auch genügend Bestellungen, um Dir mehr Webspace leisten zu können ;-)
;-);-);-);-);-);-);-);-)
Bedenke vor allem, dass Cookies nicht nur in der Menge pro Host begrenzt sind, sondern auch in der jeweiligen Länge, und dass viele User Cookies nicht gerne sehen und ablehnen - und sogar entsprechende Sites umgehend verlassen.
Da gebe ich Dir bedingt Recht, natürlich sind die cookies in der Größe begrenzt (auf 4 MB!) und 20 pro Host... und auch ich bin kein Freund von Cookies, ABER nicht jeder kann sich einen so aufwendiges Session-Management erlauben wie bei amazon erlauben, DANN hat man auch die Datenbank dafür ;-)
b) ich keinen Datenmüll in der Datenbank habe (, denn was ist mit den Daten, die die Leute zwar in dem Warenkorb haben, aber nur einmal auf der Seite waren? evtl. eine weitere spalte mit nem Datum, das die Artikel nach n-Tagen wieder gelöscht werden?)
Du müsstest zum Zwecke der User-Erkennung ohnehin einen Session-Mechanismus implementieren. Dieser sollte auch über Carbage-Collection-Routinen verfügen: alle Daten abgelaufener Sessions werden gelöscht. Bei einem hinreichend mächtigen DBMS ist dies durch ein ON DELETE CASCADE in der Foreign-Key-Definition problemlos machbar.
Naja, sagen wir es mal so: Die Seiten werden für einen kleinen Laden, also läuft das ganze auf einer kleinen Mysql(NICHT ORACLE....), KEINE Foreign-Keys, keine views, statt dessen werde ich wohl mein Programm die Arbeit machen lassen....
Ich empfehle einen serverseitigen Mechanismus. Auf den Client kann man sich _nie_ verlassen.
Cheatah
Danke für Deine Antwort, werde es wohl doch über ne zusätzliche Tabelle machen....
Noch nen paar Tips?
mfg
Der Schröder
-
Hi,
Bedenke vor allem, dass Cookies nicht nur in der Menge pro Host begrenzt sind, sondern auch in der jeweiligen Länge, und dass viele User Cookies nicht gerne sehen und ablehnen - und sogar entsprechende Sites umgehend verlassen.
Da gebe ich Dir bedingt Recht, natürlich sind die cookies in der Größe begrenzt (auf 4 MB!) und 20 pro Host... und auch ich bin kein Freund von Cookies, ABER nicht jeder kann sich einen so aufwendiges Session-Management erlauben wie bei amazon erlauben, DANN hat man auch die Datenbank dafür ;-)
4MB PRO COOKIE ???? woher haste diesen Blödsinn ? - ich gebe den meisten Browsern maximal 1023 bzw. 2047 Zeichen ! und 20 cookies sind n witz.... was ist wenn er 21 artikel will ??
b) ich keinen Datenmüll in der Datenbank habe (, denn was ist mit den Daten, die die Leute zwar in dem Warenkorb haben, aber nur einmal auf der Seite waren? evtl. eine weitere spalte mit nem Datum, das die Artikel nach n-Tagen wieder gelöscht werden?)
den datenmüll kannst du anhand eines Timestamps identifizieren, und dann nach 24h löschen.....
Du müsstest zum Zwecke der User-Erkennung ohnehin einen Session-Mechanismus implementieren. Dieser sollte auch über Carbage-Collection-Routinen verfügen: alle Daten abgelaufener Sessions werden gelöscht. Bei einem hinreichend mächtigen DBMS ist dies durch ein ON DELETE CASCADE in der Foreign-Key-Definition problemlos machbar.
Naja, sagen wir es mal so: Die Seiten werden für einen kleinen Laden, also läuft das ganze auf einer kleinen Mysql(NICHT ORACLE....), KEINE Foreign-Keys, keine views, statt dessen werde ich wohl mein Programm die Arbeit machen lassen....
Ich empfehle einen serverseitigen Mechanismus. Auf den Client kann man sich _nie_ verlassen.
Cheatah
Danke für Deine Antwort, werde es wohl doch über ne zusätzliche Tabelle machen....
übrigens: http://www.whiskyworld.de läuft momentant unter einem LAMPS system, Suse7.2, Apache1, MySQL PHP und SSL, und ein warenkorbsystem ist kein aufwand den sich nur AMAZON leisten kann...
mfg
Korbinian Bachl
www.whiskyworld.de-
Hi,
Da gebe ich Dir bedingt Recht, natürlich sind die cookies in der Größe begrenzt (auf 4 MB!) und 20 pro Host...
4MB PRO COOKIE ???? woher haste diesen Blödsinn ? - ich gebe den meisten Browsern maximal 1023 bzw. 2047 Zeichen ! und 20 cookies sind n witz.... was ist wenn er 21 artikel will ??
definiert sind 4 Kilobyte und in der Tat 20 pro Host. Aber wie kommst Du auf die Idee, man müsse pro Artikel einen eigenen Cookie anlegen? Das ist schon vom Verwaltungsaufwand her zu hoch - sämtliche Informationen haben im selben Cookie zu stehen.
ABER nicht jeder kann sich einen so aufwendiges Session-Management erlauben wie bei amazon erlauben, DANN hat man auch die Datenbank dafür ;-)
Wieso "aufwändig"? Ein primitives Session-Management erfordert ein wenig Gehirnschmalz und ein paar Stunden Arbeit; oder aber man greift auf verfügbare Session-Systeme zu. PHP beispielsweise liefert gleich eines frei Haus.
den datenmüll kannst du anhand eines Timestamps identifizieren, und dann nach 24h löschen.....
Richtig. Und wenn cron-Jobs (oder ein Äquivalent) nicht zur Verfügung stehen, ist der Provider einfach schlecht gewählt ;-)
Naja, sagen wir es mal so: Die Seiten werden für einen kleinen Laden, also läuft das ganze auf einer kleinen Mysql(NICHT ORACLE....), KEINE Foreign-Keys, keine views, statt dessen werde ich wohl mein Programm die Arbeit machen lassen....
Tja, wenn Du MySQL verwendest, ist die Datenintegrität in der Tat Dein Job. Nun, das ist etwas mehr Aufwand, aber macht die Sache noch lange nicht unmöglich.
übrigens: http://www.whiskyworld.de läuft momentant unter einem LAMPS system, Suse7.2, Apache1, MySQL PHP und SSL, und ein warenkorbsystem ist kein aufwand den sich nur AMAZON leisten kann...
Gute Zusammenfassung :-)
Cheatah
-
Hi,
Da gebe ich Dir bedingt Recht, natürlich sind die cookies in der Größe begrenzt (auf 4 MB!) und 20 pro Host...
4MB PRO COOKIE ???? woher haste diesen Blödsinn ? - ich gebe den meisten Browsern maximal 1023 bzw. 2047 Zeichen ! und 20 cookies sind n witz.... was ist wenn er 21 artikel will ??
definiert sind 4 Kilobyte und in der Tat 20 pro Host. Aber wie kommst Du auf die Idee, man müsse pro Artikel einen eigenen Cookie anlegen? Das ist schon vom Verwaltungsaufwand her zu hoch - sämtliche Informationen haben im selben Cookie zu stehen.
Sorry NATÜRLICH KB nicht MB!!!!!!!!! Denk nur an die Übertragung bei einem Modem...
Und jeden Artikel in einen Cookie zu packen wäre irgendwie DAUABER nicht jeder kann sich einen so aufwendiges Session-Management erlauben wie bei amazon erlauben, DANN hat man auch die Datenbank dafür ;-)
Wieso "aufwändig"? Ein primitives Session-Management erfordert ein wenig Gehirnschmalz und ein paar Stunden Arbeit; oder aber man greift auf verfügbare Session-Systeme zu. PHP beispielsweise liefert gleich eines frei Haus.
Aufwendig insofern, dass ich nicht php benutze ;-)
den datenmüll kannst du anhand eines Timestamps identifizieren, und dann nach 24h löschen.....
Richtig. Und wenn cron-Jobs (oder ein Äquivalent) nicht zur Verfügung stehen, ist der Provider einfach schlecht gewählt ;-)
Naja, sagen wir es mal so: Die Seiten werden für einen kleinen Laden, also läuft das ganze auf einer kleinen Mysql(NICHT ORACLE....), KEINE Foreign-Keys, keine views, statt dessen werde ich wohl mein Programm die Arbeit machen lassen....
übrigens: http://www.whiskyworld.de läuft momentant unter einem LAMPS system, Suse7.2, Apache1, MySQL PHP und SSL, und ein warenkorbsystem ist kein aufwand den sich nur AMAZON leisten kann...
Wie schon gesagt, dieser wird für EINEN KLEINEN LADEN!
mfg
Der Schröder
Danke für Eure Antworten!
-
Hi,
Wieso "aufwändig"? Ein primitives Session-Management erfordert ein wenig Gehirnschmalz und ein paar Stunden Arbeit; oder aber man greift auf verfügbare Session-Systeme zu. PHP beispielsweise liefert gleich eines frei Haus.
Aufwendig insofern, dass ich nicht php benutze ;-)
irgendwas serverseitiges benutzt Du. Also ist es wahrscheinlich, dass Du ein Modul o.ä. finden kannst, welches das Session-Management für Dich übernimmt.
Wie schon gesagt, dieser wird für EINEN KLEINEN LADEN!
Trotzdem soll es funktionieren und handhabbar sein, oder? ;-)
Cheatah
-
-
-
-
-