Projekthilfe für Bestellungs-DB inkl. Abos

ninox023

Neuer Benutzer
Beiträge
1
Hallo zusammen,
auf der Suche nach einem DB-Forum bin ich auf Euch gestoßen. Zum aktuellen Zeitpunkt möchte ich tiefer in das Datenbankthema einsteigen und hatte mir überlegt, dass es am besten mit einem etwas umfangreichen Projekt ist. Da ich mir mein Wissen hauptsächlich alleine durchs "Abschauen" beigebracht habe, komme ich bei komplexeren Fragestellungen an meine Grenzen.

Es geht dabei um eine mySQL-Datenbank, welche alle Informationen eines kleinen Unternehmens speichern, auswerten und analysieren soll. Im weiteren Verlauf möchte ich eine GUI mit Python programmieren, damit Eingaben in die DB gespeichert sowie auch diverse Status angezeigt werden können. Das ist jedoch zum aktuellen Zeitpunkt nicht der Fokus. Zunächst möchte ich dafür die Grundlage bauen.

Aktuell habe ich so meine Probleme mit den "Produktionsdaten". Das Unternehmen stellt Produkte her, welche produktabhängige Produktionstage haben (zwischen 7 und 21 Tagen mit verschiedenen Produktionsstatus). Die einzelnen Produkte können vom Kunden zu einem gewünschten Datum bestellt werden, darauf aufbauend erfolgt die entsprechende Produktion des Produktes. Die Produkte werden nicht gelagert. Ferner kann der Kunde auch ein Abo bestellt, sodass er eine wöchentliche Lieferung entweder am Di oder Do bekommt. Bei dem Abo habe ich das entsprechenden Start- und Enddatum des Abos, wodurch die wöchentliche Lieferung sich berechnen lässt und somit auch die Produktionstage der einzelnen Produkte. Ich weiß jedoch nicht, wie ich die Informationen für die Produktionen von der Bestell- und Abo-Tabelle verknüpfen soll, sodass ich eine Übersicht erhalte, an welchem Tag die Produktion des entsprechenden Produktes gestartet werden soll bzw. in welchem Produktionsstatus sich die Produkte der einzelnen Kunden befinden. Ich möchte mit einer dynamischen Struktur einen Tag auswählen, sodass ich hier den Status der Produkte sehe und für welchen Kunden diese Produkte sind. Im Anhang habe ich einen erster Entwurf als ER-Diagramm erstellt.

Aktuell wird die Produktion jeden Montags für zwei Wochen erstellt. Dies wird alles in einer Access-Datenbank abgebildet und mit einem VBA-Skript erfolgt das Speichern der Produktionsstatus der Produkte mit Datum in einer separaten Tabelle. Eine Übersicht wird entsprechend ausgedruckt. Falls innerhalb dieser zwei Wochen Produkte bestellt werden, welche zeitlich noch produziert werden können. Wird dies entweder auf dem Ausdruck vermerkt (sehr fehleranfällig) bzw. in der DB eingetragen und erneut für die zwei Wochen Ausgedruckt (hoher Aufwand). Da u. a. auch Buchungsdaten in einer anderen Access-Datenbank vorhanden sind, möchte ich alles komplett in einer mySQL-Datenbank auf einem Server abbilden.

Ich bin um jeden Tipp dankbar. Ideen zum Modifizieren des ER-Diagramm sind gerne erwünscht. Freue mich auf euren Input.

Besten Dank schonmal für die Hilfe.
 

Anhänge

  • ER-Diagramm.PNG
    ER-Diagramm.PNG
    84,7 KB · Aufrufe: 5
Werbung:

dabadepdu

Datenbank-Guru
Beiträge
919
Wenn ich „Produkt“ lese, denke ich an eine abstrakte Produktliste, nicht an Produktionsplanungsdaten. Für mich 2 verschiedne Paar Schuhe.

7-21 Produktionstage kann alles mögliche sein. Bestimmte Werktage, 7 Arbeitstage am Stück, 7 Tage am Stück, ein bestimmter Tagesrhythmus, abhängig von der Maschinenkapazität oder der einzelner Maschinen.. kann man so nichts zu sagen.

Buchungsdaten wovon? Abozahlungen? Allen Zahlungen? Materialbuchungen?

Produkt-Status, für mich Produktionsstatus einer (Dauer)Bestellung: Wenn es alle 2 Wochen montags einen Plan gibt und wenn es Abos gibt und Adhoc Bestellungen, wie passt das zusammen? Das ist eher eine Frage der realen Abläufe. Die wären bei Abo und 7-21 festen Produktionstagen m.E. ziemlich fest, je geringer die Fertigungstiefe, desto fester. Adhoc Bestellungen passen da aber kaum mit rein. Vielleicht sind eure Produkte auch Lebensmittel und diese Abläufe sind aus Hygienegründen, Haltbarkeit usw. noch viel fester, als gedacht.

Ich denke, das musst Du noch etwas erläutern, was dahinter steckt.

Und Du hast zwar nicht danach gefragt, aber ich erlaube mir, Dir eine andere DB zu empfehlen, nimm lieber Postgres, gerade wenn Du neu anfängst.
 
Oben