dedlfix: MySQL SUM mit GROUP Problem

Beitrag lesen

Tach!

Sorry - habe ich nicht verstanden. Wie würde denn meine Abfrage konkret aussehen

In meiner Antwort waren zwei Aspekte. Der eine und eigentlich wichtigere war, zunächst einmal auf Ursachenforschung zu gehen, warum es denn zu dem unerwarteten Ergebnis kommt. Die Abfrage sieht dazu konkret so aus, wie du sie bereits hast, aber die Summierung und die Gruppierung kommt raus. Gegebenenfalls musst du die Feldliste erweitern oder auch * selektieren, damit du sehen kannst, welche Datensätze in der Vereinigungsmenge drin sind und ob das die gewünschten sind. Oder ob nicht vielleicht ein Join-Fehler drin ist, der zu einem ungewollten kartesichen Produkt geführt hat.

Wenn du die Ursache für die falsche Summe erkannt hast, wird dir vielleicht auch einfallen, wie das Problem zu beheben ist.


Der zweite Teil war da, um eine generelle Alternative zu Joins aufzuzeigen, die ich für einfacher lesbar halte.

SELECT a.x aliasX, (SELECT y FROM b WHERE a.id = b.id_a) aliasY FROM a

Eine Aufgabenstellung für dieses Beispiel wäre: gibt mir Daten aus Tabelle a, repräsentiert hier durch a.x, es können aber auch beliebig viele Felder aus a gelistet werden. Und gib mir dazu genau einen Wert, der aus dem Feld y der Tabelle b ermittelt wird, der zum aktuellen Datensatz der Tabelle a passt. Die Beziehung ist dabei, dass in b das Feld id_a auf die id in a verweist. Statt dem reinen y kann auch eine Rechnung genommen werde, Hauptsache es entsteht in dieser Subquery nur ein einzelnes Ergebnis. Der Wert, der in dem Gebilde in ()-Klammern entsteht, kann auch in der Hauptquery weiterberechnet werden:

SELECT a.x aliasX, (SELECT y FROM b WHERE a.id = b.id_a) * 42 aliasY FROM a

oder

SELECT a.x aliasX, SUM((SELECT y FROM b WHERE a.id = b.id_a)) aliasY FROM a

Die doppelten Klammern sind notwendig, weil einerseits das SUM() ein Klammernpaar erfordert, andererseits Subquerys auch noch mal eigene Klammern benötigen.

Wenn du dieses Prinzip verstanden hast, sollte es eigentlich ein leichtes sein, es auf deinen Anwendungsfall anzuwenden.

Geh dabei schrittweise vor, schau dir die Zwischenergebnisse an, die die Abfragen liefern, vor allem auch bevor du Zusammenfassungen einbaust. Der Vorteil an solchen Correlated Subquerys ist auch, dass man sie recht leicht rauslösen und separat testen kann, was bei einem Join schlecht bis gar nicht geht.

dedlfix.