SQL Befehl über mehrere Tabellen

[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.