Webshop ohne Useranmeldung / Wo Warenkorb speichern?
Aqua
- programmiertechnik
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
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
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
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
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
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
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
Ich bin zwar nicht Fabulous Fabian ...
ich dachte, du willst es _von Hand_ in _PERL_ machen ??
Frank
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
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
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
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
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
Hallo Tom!
Dann müsste man es aber wieder im URL / Cookie übergeben...?
Ist das echt sinnvoll?
LG
aqua
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
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
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
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