Datenbankstruktur für Bestellabwicklung

[Forumsgast]

Ich arbeite gerade an einem E-Commerce Projekt und bin gerade an dem Punkt, die notwendingen Datenbankeintragungen nach Abschluss der Bestellabwicklung vorzunehmen.
Im Angebot stehen sowohl gewöhnliche Produkte als auch individuelle. Ein gewöhnliches Produkt ist ein simples Produkt mit der Produktnummer, dem Preis und einer gewünschten Menge. Ein individuelles Produkt kann sich bspw. folgendermaßen zusammensetzen: Individuelles Produkt = 20% von Produkt A, 60% von Produkt B und 20% von Produkt C, sozusagen eine Mischung.

Die gewöhnlichen Produkte werden nach folgendem Schema in der Tabelle order_item gespeichert: Produktnummer, Preis, Menge und Auftragsnummer. Dass die individuellen Produkte nicht in dieses Muster passen, sollte einleuchtend sein.

Als Erstes habe ich mir überlegt, die bestehende Tabelle zu modifizieren und notwendige Felder hinzuzufügen, z.B. ist_individuell und parent. Im Falle, dass ist_individuell gesetzt ist, kann mit Hilfe von parent die Mischung zusammengestellt werden. Ein drittes Feld für den Prozentsatz würde das ganze vervollständigen. Nachteil ist, dass die Mischung meist aus mehreren Zeilen bestehen wird und somit einige Felder unnötig mehrfach mit demselben Wert belegt sind.

Ein zweiter Lösungsansatz ist, mit serialize() oder json_encode() zu arbeiten. Das wäre natürlich eine sehr bequeme Methode.

Drittens kam mir in den Sinne, zwei eigene Tabellen für die individuellen Produkte anzulegen. Einmal für die Mischung an sich und einmal für dessen Produkte, aus denen sie sich zusammensetzt. In die Tabelle order_item würde anstatt einer Produktnummer eine Mischungs-Id eingesetzt werden.

Mein Verstand sagt mir, dass der letzte Weg womöglich der Beste ist. Alles in einer Tabelle zusammenzufassen erscheint mir widersinnig. Was meint ihr?

[Forumsgast]

Dass man das nicht pauschal beantworten kann. Wenn Du die Anwendungsdomäne präzise beschreibst, bekommst Du vielleicht auch mehr als eine Pauschalaussage.

[Forumsgast]

Kann sich der Kunde diese individuellen Mischungen selbst zusammenstellen?
Wenn ja, würde ich so vorgehen:

tabelle für die Produkte: id | bezeichnung | .....
tabelle für die Mischungen: id | produkt_id | anteil (wenn bestellung nur aus einem Produkt besteht eben 100%)
tabelle für die Bestellungen: id | mischungs_id | .....

ob das jetzt in deinem speziellen Anwendungsfall sinnvoll ist kann ich nicht sagen. Aber so wie ich deine Anforderung verstanden habe wäre das "mein" Weg an das Ganze ran zu gehen.

[Trainmaster]

Die Anwendung sieht wie folgt aus:

Der Kunde kann sowohl individuelle als auch gewöhnliche Produkte in seinen Warenkorb legen. Hat er seine Wahl getroffen, folgt im Anschluss die Bestellabwicklung. Am Ende dieses Prozesses wird durch Klicken des "Bestellung abschicken"-Buttons eine ganze Reihe von Datenbankeintragungen vorgenommen.

Inwiefern sich gewöhnliche Produkte von den individuellen unterscheiden, habe ich bereits oben ausgeführt. Mir geht es nun konkret darum, wie ich am Besten die Produkte aus dem Warenkorb in eine Tabelle für die Produkte der Bestellungen eintrage. Momentan handhabe ich es folgendermaßen:

Tabelle für Produkte: id | Produktnummer | Preis | Steuerklasse | Erstellungsdatum | Änderungsdatum
Tabelle für Bestellungen: id | Auftragsnummer | Rechnungsnummer | Gesamtbetrag | Datum etc.
Tabelle für Produkte der Bestellungen: id | Auftragsnummer | Produktnummer | Preis | Anzahl | Gewicht


Ein individuelles Produkt, sprich Mischung, passt nicht in diese Struktur der Tabelle für Produkte der Bestellungen. Nun habe ich mir gedacht, die Tabelle zu modifizieren:

Tabelle für Produkte der Bestellungen (NEU): id | Auftragsnummer | Produktnummer | Preis | Anzahl | Gewicht | Ist_mischung | Parent


Im Nachhinein bin ich nicht mehr recht davon überzeugt, ob das geschickt ist, alle möglichen Produkte einer Bestellung in einer Tabelle zu soeichern. Aus diesem Grund habe ich mir etwas anderes überlegt:

Tabelle für Produkte: id | Produktnummer | Preis | Steuerklasse | Erstellungsdatum | Änderungsdatum
Tabelle für Mischungen: mischung_id | weitere Mischungsspezifische Felder
Tabelle für Produkte der Mischungen: mischung_id | Produktnummer | Prozentsatz
Tabelle für Bestellungen: id | Auftragsnummer | Rechnungsnummer | Gesamtbetrag | Datum etc.
Tabelle für Produkte der Bestellungen: id | Auftragsnummer | Objektnummer (= Produktnummer oder Mischungs-Id) | Preis | Anzahl | Gewicht


Ich hoffe meine Ausführungen sind präzise genug um die Sachlage zu beurteilen und eine etwaige Empfehlung auszusprechen.

[Forumsgast]

Ist es denn überschaubar bzw. gibt es eine Limitierung bei den individuellen Bestellungen für die Anzahl an Komponenten?

[Trainmaster]

Die Limitierung ist momentan auf maximal 5 Komponenten beschränkt, kann aber in Zukunft angehoben werden (schätzungsweise auf max. 10). Über das Verhältnis von individuellen zu gewöhnlichen Produkten kann ebenfalls nur gemutmaßt werden. Es ist nicht absehbar, ob eher mehr gewöhnliche Produkte oder individuelle Produkte bestellt werden. Aus diesem Grund rechne ich momentan mit 50/50.

[Forumsgast]

Dann mach es dir doch ganz leicht.

neue Tabelle; individuelles Produkt
Bestell ID | Produkt 1 ID | Produkt 1 % | Produkt 2 ID | Produkt 2% .... lalala

Wenn der Kunde nun nur 3 Sachen nimmt; dann sind halt 4 und 5 leer oder halt bis 4-10.

[Forumsgast]

Dann mach es dir doch ganz leicht.

Bloß nicht - Normalisierung ist nicht zum Spaß da.

Mit deinem jetzt „ganz leicht machen“ machst du es dir gleichzeitig in Zukunft ganz schön schwer, wenn das System flexibel erweitert werden soll.

[Trainmaster]

@ KlausMeier
Wie bereits ChrisB geschrieben hat, finde ich ein solches Konzept alles andere als optimal.


Ich denke, dass ich den Weg über zwei extra Tabellen für die Mischungen gehen werde. Damit bleibt das System flexibel und gut erweiterbar. Sollte dennoch etwas dagegen sprechen, bitte ich um eure Meinungen/Empfehlungen. Mittlerweile sollten meine Darstellungen soweit ausreichend sein, um mehr als eine Pauschalantwort liefern zu können.

[Forumsgast]

Also sorry, ich finde nach wie vor die Ausführen mehr als unvollständig.

Bspw.
- werden die Mischungen als Lot mit einer neuen Bestellnummer versehen?
- werden Preise für Mischungen aus den Einzelpreisen berechnet oder gibt es viell. individuelle Angebote
- werden viell. verschiedene Steuersätze zu Grunde gelegt?
- Gibt es im System Preisstaffelungen und wie wird bei Mischungen damit umgegangen?

Ich bin selbst kein Kaufmann, aber ich befürchte, Du solltest Dich erstmal mit der Materie selbst beschäftigen, bevor Du etwas umsetzen kannst.

[Trainmaster]

1. Sofern ich diese Frage richtig aufgefasst habe: Sämtliche Produkte einer Bestellung, ganz gleich ob individuell oder gewöhnlich, werden in der Bestellabwicklung unter einer Auftragsnummer zusammengefasst.

2. Der Preis einer Mischung wird aus verschiedenen Faktoren berechnet, u.a. in Abhängigkeit der Verpackung oder der jeweiligen Einzelpreise der Produkte zu ihrem prozentualen Anteil. Fakt ist, der Preis einer Mischung steht samt mischungspezifischen Informationen in der Session und wir am Ende des Bestellprozesses in die Datenbank übertragen.

3. Ja, es können theoretisch verschiedene Steuersätze zu Grunde liegen und diese werden bei der Preis-/Mehrwertsteuerberechnung berücksichtigt.

4. Nein, Preisstaffelungen sind ausgeschlossen.


Natürlich kann ich noch viele weitere Details aufzählen, ist dies aber notwendig? Fakt ist: die Daten, welche am Schluss der Bestellung in die Datenbank eingetragen werden, sind alle in der Session abgelegt. Das heißt, dass sämtliche Prozesse der Preisberechnung bereits abgeschlossen sind. Mir geht es einzig und allein darum, Warenkorbdaten aus der Session in die Datenbank zu schreiben.

Nachdem grundverschiedene Produkte im Warenkorb stehen können, mit unterschiedlicher Beschaffenheit und Eigenschaften, muss ich mir die Frage stellen, ob es sinnvoll ist, die Produkte des Warenkorbs zwanghaft in eine Tabelle zu zwängen oder den Umweg über mehrere Tabellen und damit mehr Struktur und Flexibilität gehen soll.

[Forumsgast]

Mir geht es einzig und allein darum, Warenkorbdaten aus der Session in die Datenbank zu schreiben.

Dann stellt sich die nächste Frage - wozu werden die Daten in der Datenbank - aktuell und perspektivisch - genutzt? Willst Du viell. später eine Waren/Lagerwirtschaft anbinden, wird es schwierig, wenn man die Daten für die Einzelbestandteile nicht atomar speichert. Gleiches gilt vielleicht für eine Verpackungsmaschine/Versandkostenkalkulation. Da hast Du Dir dann mit JSON wunderbar in den Fuß geschossen.

Zur Rechnungslegung reichts das vielleicht aus. Willst Du die Waren aber unabhängig vom Kunden oder gar unabhängig von der Mischung auswerten, hast Du plötzlich Riesen-Probleme.

[Trainmaster]

Die Daten werden vor allem für verwaltungsspezifische Aufgaben benötigt (Rechnung erstellen, Lieferschein etc.) aber auch zu statistischen Zwecken (Verkaufsvolumen in einem bestimmten Zeitfenster o.ä.). Momentan erfolgen diese Schritte ohne eine Wawi, eine Anbindung ist aber geplant. Meine anfängliche Überlegung, mit JSON zu arbeiten, habe ich mir wieder aus dem Kopf geschlagen. Deine Darstellung zeigt, wieso das keine gute Idee ist.

Infolgedessen sollte ich das Konzept, das eine Mehrzahl von Tabellen vorsieht, in Angriff nehmen. Meinem Verständnis nach kommt es einer atomaren Speicherung der Daten am Nächsten. Dennoch werde ich mich abermals hinsetzen und über die genaue Vorgehensweise nachdenken. Schließlich sollen Probleme mit der Anbindung an eine Waren/Lagerwirtschaft bereits im Voraus vermieden werden.