warenkorb per DB

[SOB22]

hallo,

ich programmiere gerade einen OnlineShop und bin noch in der Designphase. Eine Sache bei der ich noch überlege, wie man sie am sinnvollsten löst, ist der Warenkorb.
Die eine Möglichkeit, die ich auch schon hier im Forum des Öffteren gelesen habe, ist die, dass man sobald ein Kunde auf den "zum Warenkorb hinzufügen" Button klickt, eine Eintrag in der DB gemacht wird, mit der SESSIONID des Kunden und der ArtikelID, des ausgewählten Kunden.

Nun habe ich aber folgendes Problem mit dieser Methode. Wenn ein Kunde, nun die Bestellung abschließt, wird die Warenkorb-Tabelle an hand der SESSIONID überprüft und alle Artikel mit der passenden SESSIONID werden ausgegeben bzw. dann auch bestellt. Gleichzeitig werden die Werte dann wieder aus der Warenkorb-Tabelle gelöscht.

So weit so gut. Aber was passiert wenn ein Kunde einfach von der Seite geht, ohne die Bestellung durchzuführen?! Dann bleiben die Werte doch in der Warenkorb-Tabelle stehen?!
Oder gibt es eine Möglichkeit diese Werte zu löschen, also von nicht ausgeführten Bestellungen?

Gruß Tim

[TobiaZ]

*verschieb* BS

Oder gibt es eine Möglichkeit diese Werte zu löschen, also von nicht ausgeführten Bestellungen?

Na klar! du gehst halt von Zeit zu Zeit die DB durch und löschst alle einträge mit abgelaufener session. Wo liegt das Problem?

[SOB22]

hmm ok.
Man könnte doch zB eine Timestamp Feld anlegen, und dann per Skript alle die älter als heute sind löschen. Die sind ja dann auf jeden Fall nicht mehr aktuell ?!

[TobiaZ]

das wäre auch ne möglichkeit.

[wahsaga]

Re: warenkorb per DB

wozu denn überhaupt die daten in einer DB ablegen?

reicht es denn nicht aus, die artikel-IDs so lange nur in der session zu behalten, bis der kunde wirklich bestellt? dann kann man sie ja immer noch in die DB schreiben - als wirklich abgeschlossene bestellung.

aber den warenkorbinhalt auch in die DB zu legen, während dieser noch gefüllt wird, erscheint mir unsinnig.

[DanielD]

Hm wir handlen es bei unserem Onlineshop System auch so dass die Daten in ner Tabelle gespeichert werden, id | session | artikelid | optionid | menge | timestamp .... im Adminbereich gibts ne Funktion MySQL-Tabellen säubern, die Datei empfehlen wir als Cronjob einmal pro Woche ausführen zu lassen, löscht alle Warenkorb EInträge die älter sind als 24 Stunden und sonstigen Müll der sich ansammelt .... funktioniert sicher und gut ... was will man mehr?

mfG

[Lodi]

Seh ich genauso wie wahsaga.

Als ich bei meinem kleinen Shop noch in der Entwicklung war, wollte ich auch erst den Warenkorb als Tabelle realisieren. War aber hauptsächlich deswegen, weil ich mich da noch sogut wie gar nicht mit Sessions beschäftigt hatte und mir das wie 'n Buch mit sieben Siegeln vorkam.

Dabei reicht eine Session völlig aus, um als Warenkorb-Auffangbecken zu dienen. Wozu noch in eine Tabelle speichern? Damit der Kunde zwischendurch mal den Rechner neustarten kann?

Dadurch machst du dir nur unnötig Arbeit.

[kill_bill]

Vorteil bei Warenkörben, die in der DB abgelegt wurden, ist der, dass man, wenn man denn möchte, die im Warenkorb liegenden Artikel für eine gewisse maximale Warenkorb-Lebensdauer für diesen Kunden reservieren kann. D.h. : Wenn ein Artikel nur noch begrenzt verfügbar ist, kann der, der ihn zuerst in den Warenkorb "sichert", diesen auch bekommen. Ansonsten müßte man im Checkout-Proßess erneut kontrollieren, ob der schon im Warenkorb liegende Artikel überhaupt noch verfügbar ist, wenn nicht, gibt´s ein langes Gesicht...

Nebenbei können neugierige Admins besser sehen, was denn so aktuell im Warenkorb liegt.

Zum Thema CronJob von DanielD: Man kann sich auch eine Zufallszahl 1 aus 100 pro Seitenaufruf ausgeben lassen und immer, wenn sie mit Deiner "Glückszahl" übereinstimmt, wird eine entsprechende Query zum Abtransport alter Warenkörbe ausgeführt.

[TobiaZ]

ich denke die entscheidung ob session oder nicht, hängt davon ab, wie groß der warenkorb ist.

es soll durchaus schon verwendungen gegeben haben, wo sessions gnadenlos dran verzweifelt wären...

[marc75]

ob man die artikel in der DB oder Session speichert kommt drauf an was man den Kunden alles anbieten will.

Ich pers. benutze die DB, und wenn sich ein kunde regst. und seine Email nicht gleich freischaltet biete ich ihm bis zu 1 Woche danach noch den letzten WK an.

Aber was passiert wenn ein Kunde einfach von der Seite geht, ohne die Bestellung durchzuführen?!

dafür lasse ich bei der Bestellabwicklung ein Delete durchlaufen der alle Artikel die älter als X Tage sind löscht.

[TNDKillian]

Ich würds auch mit ner Datenbank machen und dann alle 12-24 Stunden oder so die einmal durchchecken lassen und alles was älter als 12-24 stunden ist gnadenlos löschen. Mit dem reservieren kann man dann ja als extra "feature" einabuen und die reservierten sachen für sagen wir mal 2 tage in einer DB speichern. Wenn es bis dahin nicht bestellt wurde, wirds gelöscht.

@DanielD : Einmal pro woche wird das script gestartet....meine güte was für eine masse an müll sich da zusamnmen sammelt inenrhalb von einer woche, was die DB doch nicht gerade fixer macht....

[DanielD]

das kommt wohl auf die größe des shops an .... bei amazon würd der server da wahrscheinlich schnell die grätsche machen, bei tante emmas onlineshops kannste auch ganz aufs löschen verzichten weil mans perfomancemäßig auch in 5 jahren nicht merken wird ....

mfG