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.
Achso, es muss also für alle selektierten Felder eine Bildungsvorschrift oder Gruppe existieren, oder?
Oder nur für die Tabelle in welcher gruppiert wird?
Stehe jetzt auf dem Schlauch!!!
Also ich habe den Artikel Einführung in Joins gelesen und fasse das so auf, dass durch den Join ja quasi nur noch eine (virtuelle) Tabelle besteht. Da müsste in meinem Fall ja nach allen selektierten Spalten außer anzahl und preis gruppiert werden.
Also wenn das so wäre hätte ich es glaub ich verstanden, da nun für mich wieder eine Logik einkehrt.
Für dich als Mensch ist klar
Tabelle r
4711 | 1234Tabelle k
4711 | Max | MustermannTabelle p
1234 | Artikel_1 | 13,95 | 1
1234 | Artikel_2 | 14,95 | 1Wenn 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 | 1Klar 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 | 1Was 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
...
LG fr@gma