Aqua: Webshop ohne Useranmeldung / Wo Warenkorb speichern?

Hallo!

Programmiersprache ist PERL.
Geplant ist ein Webshop ohne(!) User-Anmeldung.

Das laueft dann so ab:
Der user kommt auf die Seite, klickt auf ein Produkt
welches ihn interessiert,  legt es in den Warenkorb,
surft weiter herum, findet noch 2 interessante Produkte.

Nun hat er 3 Produkte im Warenkorb.

Alle verfügbaren Produkte sind in der Datenbank.

id  produktname

1   Kaffee
 2   Apfel
 3   Birne
 4   Brot
 5   Schokolade
 6   Zigaretten
 7   Alkohol

Der User entschloss sich also Produkt  Nr.  1, 6, und 7 zu nehmen.

ok weiter beim User.
Der User hat einen Cookie.

in dem Cookie ist seine Session-ID.
Um es uns einfach zu machen ist seine session ID  55555

Und genau da faengt das Problem an:
Wohin mit dem Warenkorb des Users?

Muss ich eine eigene Zeile in meiner Tabelle in der MySQL-DB
erstellen für diesen User bzw. seinen Warenkorb?

Alle Produkte in dem Cookie zu speichern waere auch doof oder?

Dann könnte der Cookie so aussehen:

produkte=1,7,6

Oder wohin mit dem Warenkorb?
Wie gesagt der User ist nicht eingeloggt,
nicht angemeldet,  er gibt beim "Zur Kassa gehen" seine
Personalien in die Form ein und fertig.

Wie macht man das am Professionellsten von Hand?

PHP hat da ja spielchen mit einigen Modulen aber wie gesagt
ich plane das in PERL und von Hand zu machen.

Danke,

LG
Aqua

  1. Lösung:

    Du hast die MySQL-Tablle folgender Form gegeben:

    id(1) Name(2)  sid(3) anzahl(4)
    1 Kaffee  55555 x
    2 Apfel  55555 x
    3 Birne  55555 x
    4 Brot  55555 x
    5 Schokolade 55555 x
    6 Zigaretten 55555 x
    7 Alkohol  55555 x

    (1): Die Artikelnummer
    (2): Die Artikelbezeichnung/-beschreibung
    (3): Die Session-ID
    (4): Wie oft hat der User das Produkt bestellt?

    Dann kannst du folgendes machen:

    SELECT * FROM warenkorb WHERE sid=55555

    und gut is.

    Das einzige Problem was du hast ist, dass die Inhalte der MySQL-Tabelle nicht entfernt werden, wenn der Benutzer die Seite verlässt, ohen vorher den Warenkorb geleert zu haben. Dieser Nachteil ist aber auch gleichzeitig Vorteil: So kannst du überprüfen, ob und wann und wie oft Betsllungen abgebrochen wurden und welche Produkte daran beteiligt waren.

    Denkbar wäre es, einen Timestamp zusätzlich einzufügen und bei jedem Aufruft der Webseite ein

    DELETE * FROM warenkorb WHERE timestamp>7day

    1. Hi S.

      Klaro fein und das alles haust Du natürlich in eine einzige Tabelle?
      Soviel zur normalisierung von Datenbanken.

      Das ist in der Praxis naicht machbar so *IMHO*

      LG
      Aqua

      1. Tach Aqua,

        Klaro fein und das alles haust Du natürlich in eine einzige Tabelle?
        Soviel zur normalisierung von Datenbanken.

        Gut, du weißt also, was Normalisierung ist.
        Wieso kommst du dann nicht daruaf eine zweite Tabelle als Referenz zur Warennummer zu basteln?

        Das ist in der Praxis naicht machbar so *IMHO*

        Doch. Die Idee ist nicht so schlecht.

        Grüße aus Barsinghausen,
        Fabian

        1. Hallo Fabian.

          Also 1 Tabelle mit den Produkten die es gibt
          und noch eine Tabelle "Warenkorb"

          und in "Warenkorb" dann die Session-ID,
          und daneben die Produkt-ID,
          und dann wenn ich wissen will was der User im Warenkorb hat waehle ich alle where Session-ID = 55555 oder wie?

          LG
          Aqua

          1. Hallo Aqua,

            Also 1 Tabelle mit den Produkten die es gibt
            und noch eine Tabelle "Warenkorb"

            Genau. Dann brauchst du auch zur Anzeige der Produkte nicht mit den Warenkörben hantieren, das macht das ganze simpler und schneller.

            und in "Warenkorb" dann die Session-ID,
            und daneben die Produkt-ID,
            und dann wenn ich wissen will was der User im Warenkorb hat waehle ich alle where Session-ID = 55555 oder wie?

            Genau.

            Grüße aus Barsinghausen,
            Fabian

            1. Hallo Fabian

              Irgendwie ist die Lösung aber immer noch hinkend.
              Ein Kollege zieht mich gerade damit auf dass es in PHP
              ein Modul gibt wo ich die Produkte in eine Session ID
              verfrachten kann,  und dann ganz normal aus der session
              ID wieder auslesen kann, ohne dass man irgendwas vom Produkt in
              der Session-ID sieht und man brauch auch keine DB dahinterstellen
              oder so....

              Das ist doch geil, oder?
              Kann PERL das nicht auch?

              Danke,
              Aqua

              1. Ich bin zwar nicht Fabulous Fabian ...

                ich dachte, du willst es _von Hand_ in _PERL_ machen ??

                Frank

                1. Hallo Frank

                  Wenn es was simpleres gibt waere das natürlich besser.

                  Klar will ich es in PERL machen aber über module laesst sich
                  auch reden mit mir  - warum nicht...

                  LG
                  Aqua

                  1. Hello,

                    haben Scripte in Perl denn auch einen exit-handler? (nehme ich doch stark an http://www.perldoc.com/perl5.8.0/pod/perlfaq8.html#How-can-I-do-an-atexit()-or-setjmp()-longjmp()--(Exception-handling))

                    Den braucht man für Sessions vom System, den Rest kannst Du selber machen.

                    Wenn das Script endet, müssen eben noch das $_SESSION-Array verpackt und abgespeichert werden.

                    Und beim Scriptstart holt man es nach der Useridentifikation dann wieder.

                    Grüße

                    Tom

          2. ok, ich beteilige mich mal noch etwas weiter

            äh ja, Aqua, so in dieser Weise

            Und die Abfrage wäre dann

            SELECT
                   warenkorb.*,
                   produkte.name
            FROM
                   warenkorb
            INNER JOIN produkte
            ON warenkorb.produkt_id = produkte.ID
            /** und jetzt die Where Clause **/
            WHERE  warenkorb.sessionID = 55555
            /** optional dann noch **/
            ORDER BY
                warenkorb.produkt_id ASC

            und dann bekommst du den Warenkorb, eigentlich recht simple bis auf den Nachteil (siehe mein anderes Posting) when it comes to databases.

            Frank

            1. Hallo Frank!

              Das verbinden der Tabellen mit dem Select ist sowas tolles,
              aber hey,  wann INNER, OUTER, LEFT, RIGHT und die andere
              möglichkeit gibts ja auch noch und ...

              LG
              Aqua

  2. Hello,

    da gabs schon einige Antworten von mir oder Sven Rautenberg zum Thema Daten von Post zu Post weitertragen.

    Man siehe unter

    serialize()
    base64_ecode()
    Post
    base64_decode()
    unserialize()

    Grüße

    Tom

    1. Hallo Tom!

      Dann müsste man es aber wieder im URL / Cookie übergeben...?
      Ist das echt sinnvoll?

      LG
      aqua

      1. Hello Aqua,

        Dann müsste man es aber wieder im URL / Cookie übergeben...?
        Ist das echt sinnvoll?

        Wir hatten doch auch schon mal die Variante

        "POST only" mit Variablen verpackt in _einer_ hidden-Variable.

        Da Du den Warenkorb sowieso am Ende verifizieren musst, kannst Du die Daten ruhig im DaisyChain von Seite zu Seite durchreichen. Da benötigt man keine Cookies und keine Session und keine URL-Parameter und ... (mehr fällt mit gerade nicht ein *ggg*)

        Grüße

        Tom

  3. Hi

    ** also ich bin kein PERLer **

    aber gefragt ist hier ja nicht direkt nach der Code Umsetzung in PERL sondern eher nach der Idee dahinter.

    Also wenn du schon Sessions mit SessionIDs und Client-Cookies nutzt, dann ist es recht einfach den User in der Applikation zu reidentifizieren.

    Es gibt einige Möglichkeiten, den Warenkorb irgendwo temporär hinzuspeichern:
    (1) simple Text-Dateien pro Session
    (2) erweiterte Text-Dateien mit selbstdefiniertem Format, (zb. XML wäre eine Möglichkeit) pro Session
    (3) direkt in der DB

    (1) hat den Nachteil dass du nicht gezielt auf Elemente im Warenkorb zugreifen kannst, dafür eher eine performantere Sache

    (2) mehr Overhead für das Verarbeiten der XML Struktur, dafür genau definiertes Format (mit Kopfinfos, Artikelliste etc) und direkter DOM Zugriff auf bestimmte Artikeleinträge im Warenkorb

    (3) Nachteil: ne Menge Roundtrips zum Server für jede Warenkorbaktion
    MySQL ist da nicht unbedingt ne günstige Wahl in Sachen DB (=meine Meinung)

    Ich habe in der Vergangenheit immer (2) genommen, da der Overhead für das Parsen des DOM nicht groß performance-mäßig ins Gewicht fiel, mein Warenkorb aber sehr aussagekräftig war.

    Unter PERL gehts vielleicht am einfachsten via den einfachen Textdateien (weiß nicht, wie es da mit XML Parsern aussieht und ob du solche Module nehmen willst)

    Gruß, Frank

  4. Moin!

    Programmiersprache ist PERL.

    Das ist schade, aber kein Hinderungsgrund. PHP macht das, was du willst, von ganz alleine.

    Geplant ist ein Webshop ohne(!) User-Anmeldung.

    Sowas habe ich gerade vor einem Monat realisiert.

    Das laueft dann so ab: [...]
    ok weiter beim User.
    Der User hat einen Cookie.

    Den kann er haben (macht die Session schöner), er muß es (in PHP) aber nicht.

    Und genau da faengt das Problem an:
    Wohin mit dem Warenkorb des Users?

    In PHP existiert ein Array $_SESSION, in das man beliebige Werte reinspeichern kann. Der PHP-eigene Session-Mechanismus regelt, dass der Inhalt dieses Array beim Beenden des Skriptes in einer Textdatei gespeichert wird, und beim Fortsetzen der Session wieder geladen wird. Auf diese Weise kann man programmiertechnisch diese ganze Speichergeschichte im Prinzip weglassen und ausblenden - man kann einfach davon ausgehen: Wenn das Skript gestartet wird, ist in $_SESSION das drin, was das vorhergehende Skript dort reingespeichert hat.

    Wenn du also in diesem Array ein Subarray "Warenkorb" anlegst und dort als Liste "1,5,7" für die selektierten Produkte speicherst, dann wird diese Information mit der Session auf jede weitere Seite mitgenommen, solange bis der Benutzer (der immer noch anonym ist) wieder Sachen rauslöscht oder weitere hinzufügt.

    Ach ja: Das Speichern der Anzahl gewählter Produkte wäre natürlich auch nicht verkehrt. Und wenn du es ganz toll machen willst, speicherst du die Informationen der Produkte, die du nicht ständig aus der Datenbank abfragen willst (kostet ja auch Performance), auch gleich mit in die Session - wie beispielsweise den Einzelpreis gewählter Produkte. Daraus kann man dann prima und ohne Datenbankzugriff den Gesamtpreis ausrechnen lassen.

    Muss ich eine eigene Zeile in meiner Tabelle in der MySQL-DB
    erstellen für diesen User bzw. seinen Warenkorb?

    Wenn du die Session-Informationen in einer DB speichern willst, brauchst du dafür logischerweise eine Tabelle.

    In PHP ließe sich als Ersatz für das Textdateispeichern sowas auch dranbauen. Diese Lösung würde dann aber immer das gesamte Array $_SESSION speichern müssen, nicht nur den einzelnen Warenkorb. Ich denke, auch unter Perl wäre dies eine wesentlich bessere Lösung, weil du dann problemlos weitere Session-Informationen weitertragen kannst.

    Schreibe also eine Funktion, die irgendwoher die Daten, die in der Session (identifiziert durch die ID) gespeichert sind, lädt und in eine oder mehrere Variable packt, und außerdem eine Funktion, die für das Abspeichern sorgt.

    Alle Produkte in dem Cookie zu speichern waere auch doof oder?

    Speichere nie etwas beim Benutzer, was du auf dem Server speichern kannst.

    PHP hat da ja spielchen mit einigen Modulen aber wie gesagt
    ich plane das in PERL und von Hand zu machen.

    Wie würde es denn "nicht von Hand" gehen?

    - Sven Rautenberg

    --
    "Beim Stuff für's Web gibts kein Material, was sonst das Zeugs ist, aus dem die Sachen sind."
    (fastix®, 13. Oktober 2003, 02:26 Uhr -> </archiv/2003/10/60137/#m338340>)
    1. Hi,

      ja, eigentlich sehr schön wiederholt, was ich zum Ausdruck brachte, nur mit etwas anderen Worten und näher an Perl ;-)

      Schöne Woche denn,
      Frank