Hallo
Um einen Warenkorb zu befüllen, musst du nicht nur die Daten auf dem Server (zwischen)speichern, du musst sie auch dem einzelnen Besucher zuordnen können. Das für Websites benutzte Protokoll HTTP ist dazu aber nicht geeignet. Es ist zustandslos, das heißt, die Ressource wird angefordert (z.B. Link oder Eingabe der Adresse), ausgeliefert und dann ist Schluss. Der Webserver kann nicht erkennen, dass die vielleicht eine Minute später erfolgende Anfrage vom gleichen Benutzer kommt, wie die vorhergehende.
Genau da kommt die Session ins Spiel. Sie ermöglicht, dass sich der Benutzer durch eine ID wiedererkennen lässt. Die ID wird entweder als Cookie auf dem Rechner des Benutzers gespeichert, oder sie wird als Parameter an jeden Link angehängt und so bei jedem Aufruf an den Server übermittelt.
Der User soll, wenn er sich auf einer statischen
Produkt-html-Seite befindet, einen Link "in den Warenkorb" vorfinden.
Diese Produkt-Seiten sind tatsächlich auf dem Server vorliegende
HTML-Seiten, also keine dynamische Datenbankgeschichte oder so.
Wie du mit diesem System die Informationen zu Preisen etc. lagern willst, ohne auf eine, wie auch immer geartete, Datenbank zurückzugreifen, ist mir allerdings schleierhaft. Du wirst ja nicht bei jedem Produkt im Warenkorblink eine ewig lange Kette von Parametern nach folgendem Schema übermitteln wollen.
http://example.com/shop/produkt_2455.html?produkt=2455&preis=25&farbe=schwarz
Die Nachkommastellen beim Preis habe ich jetzt mal weggelassen, weil ich aus dem Stehgreif nicht weiß, wie der Punkt zu maskieren wäre. :-)
Mit diesem System wären Fälschungen Tür und Tor geöffnet. Jeder könnte den Preis nach eigenem Gusto festlegen. Damit das nicht passiert, müssen solche Informationen auf dem Server vorgehalten werden und nur für die verarbeitenden Skripte zugänglich sein.
Du wirst also nicht um eine Datenbank herumkommen, denn im Warenkorb musst du rechnen können. Ein Kunde könnte mehrere Stück eines Produktes oder verschiedene Produkte mit einem mal kaufen wollen/sollen. Also brauchst du die jeweiligen Preise zur Berechnung des Gesamtpreises.
zu speichern wären für jedes Produkt mindestens:
- eine Produktnummer (eine ID)
- Produktname
- Einzelpreis
- falls erforderlich: Eigenschaften (Farben, Größen u.s.w.)
Du kannst auch Beschreibungen, Pfade zu Bildern des Produkts etc. in der DB speichern, um mit diesen Informationen die Seite des Produkts zu befüllen.
Legt der Kunde ein Produkt in den Warenkorb, kann mit der ID des Produkts, eventuellen Eigenschaften, der zu bestellenden Menge, die in der Session gespeichert werden, und dem Einzelpreis aus der DB immer der Gesamtpreis der Bestellung (zzgl. Versandkosten) errechnet werden.
Zum Auslösen der Bestellung brauchts dann noch persönlicher Daten wie Name und (Liefer)anschrift.
Die Daten (der Datensatz) der Bestellung (Produkte, Mengen, persönliche Daten des Bestellers) landen wohl per Email bei dir. Aber auch hier ist eine Speicherung in einer DB (mehr als nur) sinnvoll. Einerseits kann die Email auf sich warten lassen, du hast also bei Zugriff auf die Daten in der DB eine Rückfallebene, andererseits kannst du dem Kunden, bei entsprechender Pflege der Datenbestände, einen Mehrwert z.B. in Form eines Auslieferungsstatus (Bestellung eigegangen, Lieferung zusammengestellt, verschickt) geben.
Wirklich simpel ist das Ganze also nicht. Zumal meine Beschreibung bestimmt nicht allumfassend ist.
Tschö, Auge
Die Musik drückt aus, was nicht gesagt werden kann und worüber es unmöglich ist zu schweigen.
(Victor Hugo)
Veranstaltungsdatenbank Vdb 0.1