Rouven: SELECT mit JOIN und LIMIT GROUP BY Problem

Beitrag lesen

Hello,

Deine Angaben habe ich jetzt so verstanden, das SQL in meinem Statement nicht weiß, dass das Ergebnis von (anzahl*einzelpreis) zusammen zufügen ist, sondern das es auch passieren kann das die Spalten einzeln zusammen gefasst werden, indem anzahl summiert wird und einzelpreis summiert wird, oder?

nein, das habe ich damit nicht gemeint. Deine Summierung ist vollkommen in Ordnung. Du gruppierst und bildest eine Summe über die Zeilen innerhalb der Gruppe, das ist vollkommen in Ordnung - soweit ich das überblicken kann, dürfte es auch das ergeben, was du haben wolltest.

In meinem Beispiel bilde ich ja die zeilenweise Summe aus anzahl und einzelpreis.

eben, das ist soweit okay.

Dein Problem liegt in den anderen Spalten, ich zitiere nochmal von weiter oben:

SELECT
r.kundennummer,
r.rechnungsdatum,
r.rechnungsnummer,
k.anrede,
k.vorname,
k.name,
k.kundennummer,
p.rechnungsnummer,
SUM(p.anzahl * p.einzelpreis)
[...]
  GROUP BY p.rechnungsnummer

Schauen wir uns das nochmal unter der Beschreibung meines vorherigen Postings an:

  • du gruppierst nach p.rechnungsnummer. Es ist also legitim, p.rechnungsnummer zu selektieren - GROUP BY stellt sicher, dass es einen eindeutigen Wert hat.
  • SUM(p.anzahl * p.einzelpreis) ist legitim, innerhalb der rechnungsnummer wird also für die Posten die Summer über Anzahl * Preis gebildet, hier ist auch kein Zweifel
  • alle anderen Spalten sind nicht eindeutig. Wenn du den JOIN mal ohne GROUP BY laufen lässt siehst du ja, dass zeitweilig mehr als eine Zeile pro Rechnungsnummer existiert. Aus Sicht von SQL ist also NICHT sichergestellt, dass die Kundennummer in allen Zeilen die selbe ist. Es wird also von dir verlangt, entweder dafür zu sorgen, dass es eine saubere Gruppierung gibt (also r.kundennummer mit in GROUP BY aufzunehmen), oder eine Bildungsvorschrift anzugeben, welche der kundennummern verwendet werden sollen.
    Für dich als Mensch ist klar
    Tabelle r
    4711 | 1234

Tabelle k
4711 | Max | Mustermann

Tabelle p
1234 | Artikel_1 | 13,95 | 1
1234 | Artikel_2 | 14,95 | 1

Wenn ich jetzt den Join ausführe, dann KANN ja nur rauskommen
4711 | 1234 | Max | Mustermann | Artikel_1 | 13,95 | 1
4711 | 1234 | Max | Mustermann | Artikel_2 | 14,95 | 1

Klar sagst du "ist ja kein Problem, steht ja überall Max, steht ja überall Mustermann" - nicht so für SQL. Für SQL gibt es keine sinnvolle Befüllung der Tabelle, genauso gut könnte das Ergebnis deines Joins das hier sein (wohlgemerkt: für SQL, nicht im wahren Leben):
4711 | 1234 | Max | Mustermann | Artikel_1 | 13,95 | 1
4711 | 1234 | John| Doe        | Artikel_2 | 14,95 | 1

Was ist jetzt deiner Meinung nach das Ergebnis von
SELECT p.rechnungsnummer, k.vorname, k.nachname, SUM(preis * menge)
FROM ... GROUP BY p.rechnungsnummer?
Ist es vielleicht
1234 | Max | Mustermann | 28,90
oder ist es
1234 | John| Doe        | 28,90
oder ist es
1234 | Max | Doe        | 28,90
oder
...

MfG
Rouven

--
-------------------
sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
Unser Problem ist, dass wir eine Demokratie entwickelt haben, was nicht immer der richtige Weg ist  --  Bernie Ecclestone zu den lästigen Diskussionen um Regeländerungen in der Formel 1