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