Pitt: Warenkorb - Möglichkeiten

Hallo,

ich möchte mir einen Warenkorb programmieren.

aber ich weiss noch nicht wie er funktionieren soll, ob er mit cookies, mit einer session oder mit einer datenbank arbeiten soll.

gibt es da noch mehr möglichkeiten für ein warenkorb als die cookies, sessions oder datenbank??

danke im voraus

  1. Hi,

    ich möchte mir einen Warenkorb programmieren.

    aber ich weiss noch nicht wie er funktionieren soll, ob er mit cookies, mit einer session oder mit einer datenbank arbeiten soll.

    gibt es da noch mehr möglichkeiten für ein warenkorb als die cookies, sessions oder datenbank??

    Du benoetigst eine Datenhaltung. Empfehlen tut man da idR 'MySQL' oder ein kostenfreies Aequivalent oder von MS 'MSSQL Server'. - Ohne Datenhaltung wirst Du nicht gluecklich werden, wenn Du einen "Warenkorb" benoetigst.

    Gruss,
    Lude

  2. Moin!

    gibt es da noch mehr möglichkeiten für ein warenkorb als die cookies, sessions oder datenbank??

    Drei bis fünf Millimeter VA-Stahldraht?
    http://www.wanzl.de/www_root/ar08/templates/xxxxxAr08Zubehoer.jsp?language=De&organisation=001&navSeq=206

    - Sven Rautenberg

    --
    ss:) zu:) ls:[ fo:} de:] va:) ch:] sh:) n4:# rl:| br:< js:| ie:( fl:( mo:|
  3. ich möchte mir einen Warenkorb programmieren.

    aber ich weiss noch nicht wie er funktionieren soll, ob er mit cookies, mit einer session oder mit einer datenbank arbeiten soll.

    gibt es da noch mehr möglichkeiten für ein warenkorb als die cookies, sessions oder datenbank??

    Nein, allerdings bringst Du da auch einiges durcheinander. Also:

    a) Man kan einen Warenkorb problemlos in einem Cookie unterbringen, denn Cookies können mindesten 4 KByte Daten aufnehmen.

    b) Eine Session benutzt immer entweder Cookies oder die URL um jedem Benutzer (bzw. Browser) eine eindeutige Kennung zu geben.

    c) Bei Nutzung einer Datenbank mußt Du selbst entweder Cookies oder eine Session (welche eventuell selbst wiederzum einen Cookie nutzt) benutzen.

    Der Dreh und Angelpunkt bei der ganzen Geschichte ist, einen Benutzer von Seitenaufruf zu Seitenaufruf eindeutig wieder zu erkennen, denn das Protokoll HTTP selbst kennt keine durchgehende Verbindung. Diese Wiedererkennung realisiert man, indem dem Browser ein Cookie verpasst wird, welchen der Browser bei allen folgenden Anfragen wieder an den Server zurück schickt.

    Du kannst also entweder Deine Warenkorbdaten direkt in einem Cookie speichern. Der Nachteil ist, daß je größer der Warenkorb wird, desto länger dauern die Abfragen von Seiten, weil der Browser bei _jedem_ Abruf den Warenkorb an den Server sendet - auch bei Grafiken. Hast Du fünfzehn Bilder, drei Javascript-Dateien und zwei Stylesheets auf Deiner Seite und einen Warenkorb von 4 KByte, müssen für den kompletten Abruf einer Seite 84 KByte an den Server gesendet werden.

    Der Vorteil von Sessions ist demgegenüber, daß die Warenkorbdaten auf dem Server gespeichert werden und nur eine relativ kurze Kennung ("Session-ID") übermittelt wird. Dazu kommt, daß Sessions meistens automatische Datenverwaltung mitbringen, zum Beispiel um Daten, die eine Zeit lang nicht mehr genutzt wurden, selbständig vom Server zu löschen. Es ist darüber hinaus auch möglich, Sessions ohne Cookies zu nutzen, indem die Kennung an die URL angehängt wird. PHP kann dies beispielsweise vollautomatisch.

    Das Speichern des Warenkorbes in einer Datenbank ist lediglich eine Unterart von Sessions, denn auch hier brauchst Du eine Kennung, um einen Benutzer/Browser mit den Daten in der Datenbank in Zusammenhang zu bringen - landläufig bekannt als "Session-ID".
    Sowas von Grund auf selbst zu implementieren ist wahrscheinlich ungefähr das gleiche als wenn Du das Rad neu erfinden willst. Benutze lieber vorhandene Sessionmodule und passe sie an Deine Bedürfnisse an.

    Gruß,
      soenk.e