SQL Befehl über mehrere Tabellen

[Luca Haas]

Hi Leute, ich bin aktuell dabei einen SQL-Befehl zu schreiben, der mir den Umsatz und das Gesamtgewicht der gelieferten Artikel je Monat anzeigt. Ich habe allerdings das Problem, dass alle Daten in unterschiedlichen Tabellen aufzufinden sind.
Ich habe das Gewicht in der Tabelle Artikel_s, die Kosten in Rechnungpos_s und das Lieferdatum in Rechnung_s.

Mein SQL Befehl sieht aktuell so aus:

Delphi-Quellcode:

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

Er funktioniert soweit, nur dass ich das ganze noch nicht nach dem Lieferdatum sortiert habe, allerdings habe ich keine Ahnung wie ich hier eine dritte Tabelle einbaue, ohne das mir das ganze um die Ohren fliegt, könnte mir jemand dabei helfen oder hat jemand evtl einen Link zu einem Tutorial für das arbeiten mit mehr als 2 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

[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

Delphi-Quellcode:

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.

[Jumpy]

Ich würde anders herum Anfangen:

Erst die Rechnungen, eingeschränkt auf den Monat,
dazu die Rechnungspositionen,
dazu die Artikel

[Luca Haas]

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

[himitsu]

Zitat:

Zitat von Luca Haas (Beitrag 1394726)

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 :oops:

[Sherlock]

Zitat:

Zitat von himitsu (Beitrag 1394727)

Zitat:

Zitat von Luca Haas (Beitrag 1394726)

genau das habe ich gebraucht

Der Porno mit Ivana Trump und ihrem Mann?

ROFLCOPTER

Sherlock

[jobo]

Zitat:

Zitat von himitsu (Beitrag 1394724)

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

Delphi-Quellcode:

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:

Zitat von jobo (Beitrag 1394740)

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.

[jobo]

Ich denke, das ist dann am Ende eine Mischung aus der "eigenen" gedanklichen Reihenfolge und den Gegebenheiten, also Datenmodell.
Was man machen würde, ist die eine Sache, was man zur Verfügung hat die andere. Am intuitivsten geht es dann vermutlich mit einem selbst geschaffenen Datenmodell.
Ich selbst nutze gern Verschachtelung, setze alles was klar ist und easy in Klammern und friemel dann mit dem Klammerergebnis die borstigen Sachen zusammen, letztlich als ob man mit Views arbeiten würde. Meine Reihenfolge wäre also da von einfach nach kompliziert.