SQL Befehl über mehrere Tabellen

[Papaschlumpf73]

Das sind doch schon drei Tabellen...

[Luca Haas]

Ja drei Tabellen habe ich zwar schon im Befehl stehen, aber auf die Rechnung_s wird noch nicht zugegriffen, da ich es nicht hinbekomme, diese richtig zu joinen.
Ich habe sie ja bisher lediglich bei WHERE stehen

[hoika]

Hallo,
Du verwendest noch die alte Join-Syntax, das würde ich ändern

alt:
SELECT R1.Kundennr, SUM(R1.Kosten) AS Umsatz, SUM(A.Gewicht) AS Gesamtgewicht
FROM Artikel_s AS A, Rechnung_s AS R, Rechnungpos_s AS R1
WHERE A.Artikelnr=R1.Artikelnr AND R.RechnungNr=R1.RechnungNr
GROUP BY R1.Kundennr
ORDER BY R1.Kundennr

neu:
SELECT R1.Kundennr, SUM(R1.Kosten) AS Umsatz, SUM(A.Gewicht) AS Gesamtgewicht
FROM Artikel_s AS A
JOIN Rechnungpos_s AS R1 On A.Artikelnr=R1.Artikelnr
JOIN Rechnung_s AS R On R.RechnungNr=R1.RechnungNr
WHERE ???
GROUP BY R1.Kundennr
ORDER BY R1.Kundennr

D.h., die Where-Bedingungen des Joins stehen auch direkt beim Join
und das eigentlich Where filtert die Ergebnis-Menge

Das macht das ganze dann leichter zu lesen
1. Joins sind sauber erkennbar
2. Where-Filter sind sauber erkennbar

[Luca Haas]

Perfekt, genau das habe ich gebraucht, danke schön

[himitsu]

Zitat von Luca Haas:

genau das habe ich gebraucht

Der Porno mit Ivana Trump und ihrem Mann?

[Luca Haas]

Oh Sorry, ich hatte nur den Beitrag von hoika geladen, als ich meine Antwort geschrieben habe. Das hatte bei mir auch soweit geklappt, dass ich die anderen Beiträge nicht mehr wahrgenommen habe

[Sherlock]

Zitat von himitsu:

Zitat von Luca Haas:

genau das habe ich gebraucht

Der Porno mit Ivana Trump und ihrem Mann?

ROFLCOPTER

Sherlock

[himitsu]

Irgendwie kann ich mich mit dieser "altmodischen" Form des JOIN nicht richtig anfreunden.
Da seh ich auch nie schnell was wie verknubblt ist.

Delphi-Quellcode:

SELECT R1.Kundennr, SUM(R1.Kosten) AS Umsatz, SUM(A.Gewicht) AS Gesamtgewicht
FROM Artikel_s AS A
JOIN Rechnung_s AS R ON R.RechnungNr = R1.RechnungNr
JOIN Rechnungpos_s AS R1 ON R1.Artikelnr = A.Artikelnr
GROUP BY R1.Kundennr
ORDER BY R1.Kundennr

Hat das DBMS vielleicht ein Problem, weil der JOIN auf R kommt, bevor R1 gejoint wurde, weil die DB die joins auch auf ähnliche Art versucht aufzulösen / zu optimieren.
Oder wird erstmal ALLES blind mit FULL JOIN genommen und dann das WHERE drüber?

Nja, tausch einfach mal versuchsweise Reihenfolge von Rechnung_s und Rechnungpos_s.

Bei dieser FORM kannst du auch probehalber ein ON true-- einfügen oder aus einem JOIN einen LEFT JOIN machen.
abwechselnd bei allen JOINs und so schauen wer hängt, also wo dann plötzlich Daten auftauchen.

[jobo]

Zitat von himitsu:

Irgendwie kann ich mich mit dieser "altmodischen" Form des JOIN nicht richtig anfreunden.

Hat das DBMS vielleicht ein Problem, weil der JOIN auf R kommt, bevor R1 gejoint wurde, weil die DB die joins auch auf ähnliche Art versucht aufzulösen / zu optimieren.
Oder wird erstmal ALLES blind mit FULL JOIN genommen und dann das WHERE drüber?

Nja, tausch einfach mal versuchsweise Reihenfolge von Rechnung_s und Rechnungpos_s.

Bei dieser FORM kannst du auch probehalber ein ON true-- einfügen oder aus einem JOIN einen LEFT JOIN machen.
abwechselnd bei allen JOINs und so schauen wer hängt, also wo dann plötzlich Daten auftauchen.

Die "alte" Form ist eigentlich Oracle Style, zumindest gibt es (nur?) hier das (+) für outer joins. Weiß nicht ob MS da anfags auch eine Analogie gebastelt hat, aber vielleicht haben sie direkt nur "outer join" Syntax implementiert.
Die "alte" Form geht natürlich immer und überall, wenn outer (oder noch krasser) nicht gebraucht wird.

Die "Reihenfolge" sollte oder besser darf für die Ausgabe absolut keine Rolle spielen, wenn doch, Datenbank wegwerfen. Es gibt Optimizer (z.B. der alte von Oracle 8), die anhand der Reihenfolge in der From Clause einen Ausführungsplan aufbauen. Der Entwickler kann da so direkt Einfluss nehmen, wenn es denn bekannt ist und keine anderen Katastrophen eintreten.

Einfach mal schauen und ausprobieren find ich auch immer gut- na wo sind denn die ganzen Rechnungen?-, am besten find ich es sogar mit ein paar handverlesenen Datensätzen, also in fast leeren Tabellen. Damit kann man sich ganz intuitiv die Bedeutung der Joins klar machen.

Apropos: Die Where Clause sollte in der neuen Syntax nur noch zum Filtern eingesetzt werden. Das kann versehentlich schief gehen, wenn man mit Outer Joins arbeitet.

[Jumpy]

Zitat von jobo:

Die "Reihenfolge" sollte oder besser darf für die Ausgabe absolut keine Rolle spielen, wenn doch, Datenbank wegwerfen.

Der Datenbank ist das natürlich egal, aber dem Entwickler, der seine Statements logisch aufbaut vielleicht nicht:

Aufgabenstellung: Gewicht und Kosten aller Artikel aus dem letzten Jahr.
Dann ist mMn die Vorgehensweise beim Entwickeln des Statements:

Erst alle Rechnungen nehmen, Einschränkung auf das Jahr.
Dazu die Rechnungspositionen, reicht ein Left Join.
Wenn jeder Position ein Artikel entspricht, dann Artikeldetails dazu holen, wieder reicht ein Left Join.
Jetzt wie gewünscht Gruppieren/Summieren.
Wenn eine Auftragsposition noch eine Mengenangabe/Anzahl hat, das ggf. mit berücksichtigen.

Die Abfage funktioniert so vllt. nicht besser oder schneller, aber einem selber wird mMn klarer, was man da gerade macht.