nicht angemeldet
Hi,
Ich dachte nur, dass die ganzen Details vielleicht zuviel Zeit in Anspruch nehmen...?
Zeit brauchst du immer für sowas, wenn du einen kundenlogin schon geschafft hast, dann packst du einen onlineshop mit links!Genau mit dieser Einstellung haben Internet-Firmen, die es eigentlich wissen müssten, Webshops produziert und an Kunden vertickt (bzw. teilweise auch richtig fett Kohle kassiert), nur damit man hinterher feststellen konnte, dass erstens fette Sicherheitslücken eingebaut wurden, zweitens gewisse Dinge nach Monaten immer noch nicht funktionieren und drittens schlichtweg Fehler im System enthalten sind - alles ist im Endeffekt auf ein schlechtes Konzept zurückzuführen.
hab' kürzlich einen Webshop programmiert. Ist noch nicht produktiv und ausserdem gibt's keine Kreditkartenzahlungs-Unterstützung. Bestellungen werden erfasst und dann geht's an die Sachbearbeiter im Vertrieb. Vielleicht kann mir da jemand zum Thema "Online-Zahlen" einen Tipp geben?
Ich will ja wirklich nicht schwarzmalen, aber einen Webshop zu programmieren ist nun wirklich keine Tätigkeit, die jeder könnte. Dazu ist sowas viel zu sensibel. Denn es fehlt den meisten Leuten einfach der Einblick, wie man sicher programmiert, damit das System nur das tut, was es soll.
Man muss m.E. mit einem brauchbaren Datenmodell anfangen, die Use Cases ermitteln und dann kann man loslegen. Trivial ist da nichts und "mit links" geht da auch nichts. Habe ca. 80-120 Arbeitsstunden investiert und nun steht da etwas, was Grundfunktionalitäten unterstützt: Kunden-Login, Sitzungsverwaltung, Warenkörbe, Admin-Bereich für Händler (Produkte einstellen / Hochladen von Grafiken), Datentransfer in unsere Datenhaltung nach Erfassung einer Bestellung, Schaufenster ...
Ach ja, umgesetzt mit MS SQL Server und Perl 5.6
Bei einem Gästebuch ist es egal, wenn damit Schindluder getrieben wird. Die Daten sind nicht sehr wertvoll. Bei einem Webshop vertrauen die Kunden darauf, dass ihre Daten vertraulich behandelt werden - ein Vorfall wie unlängst bei Heise berichtet, bei dem Kundendaten öffentlich (zwar unverlinkt, aber zugänglich) auf dem Webserver zwischengespeichert wurden, ist mega-peinlich und _darf nicht passieren_. Zu diesem Zweck braucht man ein vernünftiges Sicherheits-Konzept - das Fachwissen für Sicherheit dürfte allgemein aber äußerst gering sein.
Sicherheit ist wichtig. Die vielleicht 15 Tabellen auf dem Datenserver sind alle GUID "entitiert". Datenzugriff also über SPs mit GUID-Übergabe (in der Regel die Session-GUID)
Der Bestellvorgang soll unter https laufen, wäre das dann OK?
es ist echt easy
- fülle ein array $warenkorb mit den artikeln zusätzlich ein array $patte und $beschreibung
und dann kannst du in einer tabbel immer den warenkorb ausgeben
$warenkorb/artikel $beschreibung $patte
------------------|-------------|------
- Artikel 1 Ein Artikel 4.50
- Artikel 2 Auto 40.000
- .....
Wo sind hier die Preise? Klar, die speicherst du in der Artikeltabelle. Und bei einer Bestellung kannst du so ganz einfach nachgucken, wie teuer der Artikel ist, indem du die Artikel-ID im Warenkorb nachguckst, und dann in der Artikeltabelle den Preis ermittelst.
Ja, ja. Was ist "datentechnisch" übrigens ein Warenkorb? Er ist eine Tabelle mit Beziehungen Produkte<->Sessions. Da stehen GUIDs drin und nichts anderes.
Was ist bei Preisänderungen? Klar, alle gespeicherten Bestellungen ändern ihren Preis automatisch mit - was zu 100% dazu führt, das Kunden bei Preiserhöhungen verärgert sind, während dir bei Preissenkungen Geld durch die Lappen geht. Also mußt du den zum Zeitpunkt der Bestellung aktuellen Preis des Produktes in der Bestellung mitspeichern. Darauf muß man aber erstmal kommen.
Preisänderungen zu "Geschäftszeiten" führen immer zu Trouble und können m.E. nicht sinnvoll unterstützt werden. Zumindest nicht in einer Browserumgebung.
Allein die logischen Abläufe in einem Webshop sind _nicht_ trivial. Folglich ist die zu erstellende Softwarelösung _nicht_ trivial, auch nicht "echt easy".
Es ist wirklich besser, ein vorgefertigtes, funktionierendes System zu verwenden. Den ganzen Gehirnschmalz, den man sonst selbst in ein neues System stecken müßte, kann man lieber sparen und in das Shopkonzept (Design, Funktionalität etc.) stecken.
Vorgefertigte Systeme sind natürlich "wirklich besser", aber die werden dann nicht verstanden und können nicht weiterentwickelt werden und bald ist alles Murks. Kann diese Annahme stimmen? Oder gibt es schon Standardsoftware "Web-Shop"?
alles Easy,
Gruss,
Luddie