Kann ich das mit einer Unterabfrage lösen und wenn ja wie?

[MiniMe]

Hallo zusammen,
ich bräuchte mal Nachhilfe.

Ich habe ein SQL, in dem u.a. Zahlen aus verschiedenen Quellen zusammengesucht und dann ausgegeben werden.
Hier eine Beispielzeile, davon habe ich mehrere.

F.BEARBEITER,
CAST(coalesce (G.Anzahl, M.Anzahl, MF.Anzahl) AS Decimal(10,5))
from TAB_MPS MP
LEFT JOIN TAB_M AS M
ON MP.ID = M.ID
LEFT JOIN TAB_G AS G
ON G.ID = MP.ID
LEFT JOIN TAB_MF AS MF
ON M.ID = F.ID
Grundsätzlich funktioniert das.
Jetzt wollte ich die Ergebnisse vergleichen und in Abhängigkeit des Ergebnisses was ausgeben, das funktioniert auch.

Ich komme nur ständig durcheinander, weil ich die gesamten coalesce Statements jedesmal komplett in die case anweisung einbauen muss.

Deswegen wollte ich wissen, ob ich das auch irgendwie als Unterabfrage so einbauen kann, dass ich nur noch den alias der Unterabfrage benutzen muss.

Danke
MiniMe

 

[dabadepdu]

Du kannst SQL Statements beliebig verschachteln.
select v.a, v.b, v.c from (select a.n as a, b.n as b, c.n as c from a join b on a.id = b.id join c on b.idx on c.id) v
In der neuen Ebene kannst Du alle SQL Befehle wieder genau so einsetzen, wie gewohnt, also weiter joinen, casten, filtern, wie Du magst.
Für diese Zwecke gibt es auch ein Konstrukt namens CTE (CommonTableExpression).
Ich weiß nur nicht, was db2 alles kann.

Zuletzt noch als Anregung:
Was Du mit "einer" Unterabfrage erreichen willst/kannst oder mit CTE oder mit verschachtelten Statements ist immer auch eine gute Frage für die Erzeugung eines Views. Er funktioniert als virtuelle Tabelle und greift zum Zeitpunkt des Aufrufs die aktuellen Daten ab.
Ein wichtiger Nutzen ist die zuverlässige Implementierung zentraler Berechnungen bzw. Vergleiche, besonders dann, wenn diese als Kerndaten immer wieder an verschiedenen Stellen benötigt werden. Also klassischer Fall für Reportingaufgaben.
Ein View ist schnell erstellt, Du brauchst Dir nur einen Namen für ein funktionierendes SQL Statement auszudenken. Da er aber einen so zentralen Charakter hat, würde ich Views als Teil des Datenmodells sehen und sie mit Sorgfalt entwerfen und verwalten. Je nach DB System ist auch das Ändern eines DB Modells mit Views nicht mehr ganz so entspannt wie ohne, da alle Objekte, die Views weiter verwenden (View auf ein View bspw) durch diese Abhängigkeit mit berücksichtigt werden müssen.

P.S.: Views gibt es mit Sicherheit in DB2, CTE wahrscheinlich aber auch

 

[MiniMe]

Danke.
Views gibt es. Die kann aber nur IT erzeugen und die gehen damit sparsam um
Ich als Endanwender muss mit SQL-Abfragen zurechtkommen.

Ich habe versucht das zu schachteln, habe aber immer Fehler bekommen
Select
MF.BEARBEITER,
select (CAST(coalesce (G.Anzahl, M.Anzahl, MF.Anzahl) AS Decimal(10,5))
from TAB_MPS MP
LEFT JOIN TAB_M AS M
ON MP.ID = M.ID
LEFT JOIN TAB_G AS G
ON G.ID = MP.ID
LEFT JOIN TAB_MF AS MF
ON M.ID = F.ID) AS ANZAHL,
Anzahl*3 AS CALC
From TAB_MF AS MF

 

[dabadepdu]

Du musst nicht die Ausdrücke schachteln, sondern komplette Statements. Das Statement, dass durch Cast und Coalesce unübersichtlich wird, schreibst Du als erstes, innen. Das komplette Statement wird in Klammern gesetzt und bekommt einen Alias wie eine Tabelle.
Damit arbeitest Du dann in den äußeren Statements weiter.
Fehler haben übrigens idR einen Namen oder eine Nummer und eine Erklärung, sie helfen beim Verständnis von SQL, sowohl dem Nutzer als auch Forenmitgliedern. Statements kann man ordentlich formatieren, da gilt das gleiche, es dient dem Verständnis aller. Formatierung gibt's idR automatisch, auf Knopfdruck oder mit Webseiten, die extra dafür da sind, ganz easy.