Verbesserungen

[Kampfgummibaerlie]

Ich sitze wieder hinter der Datenbank, habe sie teilweise neu aufgebaut, das alte Thema, nach wie vor

Mimoso und so weiter, auch wenn Mutter allen anscheins nach "bald" in die Rente/Pension geht und das alles sowieso nichtmehr brauchen wird, ich werde dennoch bei dem Thema bleiben, schätze ich, weil mich dieses "Projekt" schon einiges gelehrt hat...

Ich habe jetzt in die Datenbank eine neue Tabelle "Bestellungen" eingefügt, wo ich die Bestellungen von Produkten im Sinne von Schnittmuster und Stoff in einem Array speichere, in einer weiteren Spalte sind die "Stück" angegeben, die bestellt wurden. die Kunden-ID ist natürlich auch vorhanden, mein Gedanke geht jetzt in Richtung, ich habe auch schon Trigger-Funktions und so angelegt, welche prüfen ob im array der wert 1 ein schnittmuster und der wert 2 ein stoff ist.

wenn ich euch das schildere, fällt mir ein, eine person kann auch simpel nur einen stoff bestellen, sprich ich sollte es möglich machen, dass der wert 1 Null sein kann, und der trigger dann das ganze entsprechend durchlässt. setze mich gleich dahinter, mir fällt so direkt ein, dass ich in der Trigger Funktion einfach ein if wert[1] is Null oder so einbaue, dass das auch durchkommt.

Bin ich auf meinem Weg auf einem annähernd idealem Weg, oder mache ich irgendwas von Grundauf, auch wenn ich schon Jahre Erfahrung mitbringe, falsch?

LG und so
Kampfgummibaerlie

 

[dabadepdu]

Normalerweise hat eine Bestellung (Tabelle: bestellung) mehrere Bestellpositionen (eigenständige Tabelle: bestellposition).
bestellung hat dann bspw. die Referenz zum Kunden.
bestellposition hat immer den Verweis auf die Bestellung, idR. einen Verweis auf das Produkt (kann in deinem Fall der laufende Meter Stoff sein oder ein fertig genähtes Teil oder Garn oder Knöpfe..). Natürlich auch die Menge/Stückzahl/Kilogramm/ .. Einzelpreis. Ich vermute, das wäre das, was du als Array angelegt hast?
Optionen (wie Schnittmuster, ... ) würde ich tendentiell als Json Spalte anlegen. Je unklarer die Entwicklung, desto json. Das gilt vor allem dann, wenn die gespeicherten Daten nichts mit dem technischen Ablauf in der Software zu tun haben. Einfach gesagt, ein Wert, der nur mitgeschleift, aber nie ausgewertet, weiterverarbeitet wird, kann gern schon mal Json sein. Du musst nur an der entscheidenden Stelle in Deinem Arbeitsablauf dafür sorgen, dass diese Info, z.B. Schnittmuster, in der Produktion die richtige Person / Herstellungsprozess / Kommissionierung erreicht.
Wenn das Schnittmuster oder andere "Optionen" Auswirkungen auf den Preis haben, sollten sie eher einen festen Platz in der Tabelle bestellposition haben.

Was Du an der Stelle mit dem Trigger prüfen willst, ist mir nicht klar. Wenn es um nervige (weil gut gemeint, aber fehlerhafte) Prüfroutinen im Web geht. Lass es erstmal weg. (Nebenbei, ein Trigger ist ziemlich "weit weg" von Deinem Webserver) Nicht grundsätzlich, aber nicht während er Eingabe / Auswahl. Lieber später einen Schritt "Bestellkontrolle" mit einer separaten Seite, wo alle Positionen aufgelistet werden, mit den gewählten / gespeicherten Optionen und dem resultierenden Preis.