Unterschied zwischen WHERE und ON

[idefix2]

Hallo,

ich würde gerne wissen, was der Unterschied zwischen der WHERE und der ON Klausel in einem SELECT Statement ist. Die beiden bewirken doch genau das gleiche. Und dann gibt es noch HAVING, das nur in Verbindung mit einer GROUP Klausel verwendet werden kann und eigentlich auch nichts anderes macht?

[chaosben]

[schlecht fundiertes Halbwissen]

Wenn ich mir recht erinnere hat der Holger Klemmt mal gesagt, das die ON-Bedingung intern letztendlich genauso wie eine inhaltlich gleiche WHERE-Bedingung gehandelt wird.
Insofern: Kein Unterschied (imho).

[/schlecht fundiertes Halbwissen]

[fkerber]

Hi!

Meinst du den Unterschied zwischen

SQL-Code:

SELECT *
FROM table1, table2
WHERE table1.id = table2.id

und

SQL-Code:

SELECT *
FROM table1 JOIN table2 ON table1.id = table2.id

?

Falls ja, dann gibt es im Endeffekt (aufgrund des Anfrageoptimierers der das erste intern quasi in das 2. umwandelt) keinen Unterschied.
Von der Sache her, ist der Unterschied aber riesig. Das erste macht ein Kreuzprodukt der beiden Tabellen und filtert dann nur die raus, die du eigentlich haben willst - im Zwischenschritt hast du also Unmengen Tupel, die du gar nicht willst.


HAVING ist nochmal ne andere Baustelle.
WHERE stellt Bedingungen an einzelne Tupel wohingegen HAVING Bedingungen an ganze Gruppen stellt (daher auch nur mit GROUP BY zu verwenden.


Grüße, Frederic

[mkinzler]

Das on ist Teil eines (expliziten) Joins. Das where schränkt die Ergebnismenge ein (wirkt, wie Frederic schon geschrieben hat, auf Satzebene) Das HAVING gehört zur Gruppierung

[borwin]

Hallo

bei der ON Kausel wird die Beziehung zweier Tabellen dagestellt die durch das JOIN festgelegt wurden. Man Könnte es auch in der WHERE Klausel definieren, das ist richtig. Aber durch diese Schreibweise wird das SQL besser strukturiert. So kann man genauer erkennen was die Datensicht in der Abfrage einschränkt (WHERE) und wie die Beziehungen der Relationen zu einander (ON) sind.

Bei HAVING ist das ein bischen anders. Hier erfolgt die Einschränkung auf Basis von Aggregatfunktionen. Z.B. zum finden doppelter Datensätze

SQL-Code:

SELECT NAME, VORNAME
FROM KUNDEN
GROUP BY NAME, VORNAME 
HAVING COUNT(*) > 1

Das wäre so in einer WHERE Klausel nicht so einfach möglich.

Aber wie heißt es so schön viele Wege führen nach Rom. Das gilt auch für SQL Abfragen

Gruß
Borwin

[fkerber]

[OT]

Zitat:

Zitat von mkinzler

... (wirkt wie Frederic auf Satzebene) ...

Ich wirke auf Satzebene?! :lol:

[/OT]

[idefix2]

Offenbar bist Du Dir Deiner Wirkung gar nicht bewusst :)
Das können nämlich nur wenige.

[mkinzler]

Zitat:

Zitat von fkerber

[OT]

Zitat:

Zitat von mkinzler

... (wirkt wie Frederic auf Satzebene) ...

Ich wirke auf Satzebene?! :lol:

[/OT]

:oops: da habe ich einen Teil des Satzes nur in Gedanken formuliert und nicht getippt

[hoika]

Hallo,

Zitat:

Das erste macht ein Kreuzprodukt der beiden Tabellen und filtert dann nur die raus, die du eigentlich haben willst - im Zwischenschritt hast du also Unmengen Tupel, die du gar nicht willst.

Der Optimierer sorgt natürlich dafür,
dass im "1. Schritt" keine Unmenge an Tupeln vorhanden ist.

Was du vielleicht meinst, ist, dass die DB's der Vorzeit ... ;)
einen "angesagten" Join besser optimieren konnten als ein Where.
Das ist aber lange her.

Richtig ist einfach (wie schon gesagt),
dass durch die explizite Join-Syntax
die Abfrage strukturierter und damit besser lesbar ist
(Joins stehen als Join da und nicht "versteckt" als Where).


Heiko

[fkerber]

Hi!

Ich hatte doch oben geschrieben, dass der Anfrageoptimierer das wieder wettmacht und es behandelt wie einen JOIN.
Aber von der Bedeutung des Hingeschriebenen ist es ein Kreuzprodukt aus dem nachher was rausgefiltert wird.


Grüße, Frederic

[HeZa]

Zitat:

Zitat von idefix2

Hallo,

ich würde gerne wissen, was der Unterschied zwischen der WHERE und der ON Klausel in einem SELECT Statement ist. Die beiden bewirken doch genau das gleiche. Und dann gibt es noch HAVING, das nur in Verbindung mit einer GROUP Klausel verwendet werden kann und eigentlich auch nichts anderes macht?

Ein paar weiter Argumente:

Das Handling von INNER, LEFT OUTER, RIGHT OUTER, FULL OUTER Joins wird dadurch vereinheitlicht und das sogar Datenbank übergreifend.

Damit lassen sich OUTER Joins definieren die mit den proprietären Erweiterungen der Datenbank Hersteller nicht möglich sind (evt. dann aber ganz anders doch noch gelöst werden können :-) )

[mkinzler]

Zitat:

Damit lassen sich OUTER Joins definieren die mit den proprietären Erweiterungen der Datenbank Hersteller nicht möglich sind

Bei Oracle schon.

[idefix2]

Zitat:

Das Handling von INNER, LEFT OUTER, RIGHT OUTER, FULL OUTER Joins wird dadurch vereinheitlicht und das sogar Datenbank übergreifend

Das habe ich jetzt nicht verstanden :?

[mkinzler]

Implizite Joins ( mit Hilfe der Where clause) sind immer inner Joins (Ausser bei Oracle mit '(+)' Notatation)
Outer Joins sind sonst nur mit den neueren expliziten Joins möglich.

[idefix2]

Natürlich. Das heißt also, daß sich ein Outer join ja überhaupt nur mit on und gar nicht mit where realisieren läßt, weil beim where die Gegenseite für den Vergleich fehlt, wenn es in der gejointen Tabelle keinen passenden Datensatz gibt.

[HeZa]

Zitat:

Zitat von idefix2

Natürlich. Das heißt also, daß sich ein Outer join ja überhaupt nur mit on und gar nicht mit where realisieren läßt, weil beim where die Gegenseite für den Vergleich fehlt, wenn es in der gejointen Tabelle keinen passenden Datensatz gibt.

Vor dem ON hatten die Hersteller keine oder proprietäre Lösungen. Nun gibt es einen Standard. Lasst ihn uns nutzen.