nicht angemeldet
Hallo Rolf,
Ich hoffe, ich habe in der Geschichte keine Unlogik eingebaut
Ich verstehe sie nicht.
Liegt an mir, resp. meiner Erklärung 😉
Aus deinen Beschreibungen lese ich dieses Datenmodell heraus (erstellt mit dbdiagram.io):
Haut hin.
Ist das so richtig? Insbesondere die Kardinalitäten? Du beschreibst zwischen Table1 und Table4 eine m:n Beziehung und verwendest sie auch in der Query. Table1 scheint aber zu Table2 in einer 1:n Beziehung zu stehen.
Stell Dir einfach vor, dass der User eine Art Warenkorb (Tabelle 4) mit Artikeln (Tabelle 1) füllt (über Tabelle 3 zusammengefasst). Nun kann er zudem zu jedem Artikel ein (wie und was auch immer geartetes) Protokol (Tabelle 2) anlegen.
Insbesondere komme ich nicht damit klar, warum table2 und table4 Vorgänge enthalten und warum table4 überhaupt in der Query ist, wenn doch der User Vorgänge aus Table2 auswählt und die weiteren Vorgänge auch nur aus Table2 kommen sollen.
Nein, der User befindet sich im Warenkorb und will einen Protokollvorgang zu einem (oder mehreren) Artikel(n) erstellen.
Und genau hier möchte ich ihm alle Artikel auflisten, die der Warenkorb enthält, aber auch alle bereits angelegten Protokolle.
Und dann das hier:
Sollte ein Artikel inzwischen gelöscht sein (m.del=1), dafür aber bereits ein Tabelle2-Vorgang existent, soll dieser trortdem ganz normal angezeit werden.
Damit ist gemeint, dass wenn der Artikel aus dem Programm gestrichen ist, will ich zuvor angelegte Warenkörbe inkl. diesem Artikel und der Protokolle für diesen Artikel behalten und auch anzeigen.
Wenn Du vom User eine Vorgangs-ID als Einstieg bekommts, wären zwei bis drei Queries vermutlich besser. Die erste bestimmt die Artikel zum Vorgang, und die zweite alle Vorgänge, die mit diesen Artikeln in Beziehung stehen.
Ich fürchte auch, dass ich es splitten muss. Schade, schön wärs gewesen, wenn das elegant über eine einzige Query hätte erledigt werden können.
Danke fürs Mitdenken auf jeden Fall,
Jörg
Rolf B
Der Martin