hi,

ich verstehe nicht ganz wozu die joins da sind.

man kann doch genauso gut alles mit where verknüpfen.

bsp:

SELECT * FROM Customers c

INNER JOIN Orders o ON c.CustomerID = o.CustomerID

ist das selbe wie:

SELECT * from Customers c, Orders o

WHERE c.CustomerID = o.CustomerID

wozu dann das join ?

thx!

ist *quasi* dasselbe, weil equi join/implicit comma join gleichheit der tabellen ergibt.

da es aber ausser INNER JOIN noch LEFT / RIGHT / (FULL) OUTER JOIN gibt, ist die schreibweise IMO ziemlich obsolet.

s'Amstel

da es aber ausser INNER JOIN noch LEFT / RIGHT / (FULL) OUTER JOIN gibt, ist die schreibweise IMO ziemlich obsolet.

also muss ich das so verstehen, dass ich eigentlich garnie nicht mit "joins" direkt arbeiten muss, sondern das auch wie in meinem bsp aufgezeigt lösen kann?

Kommt drauf an.

Manche Datenbanken (vor allem ältere Mysql Versionen) haben beim sog. "Kommajoin" einen schlechteren Ausführungsplan als wenn Du die ANSI Syntax verwendest.

Bei anderen sollte es egal sein. ich persönlich finde die Schreibweise ohne das JOIN Schlüsselwort einfach zu lesen und auch schneller zu schreiben.

Beachte auch, dass Du bei der JOIN Schreibweise zwischen JOIN Bedingung und WHERE Bedingung unterscheiden musst. Auch das ist beim Kommajoin m.M. nach eleganter.

Im Prinzip aber alles Geschmackssache.

Dim

das hört sich gut an, denn mir gefällt die schreibweise ohne die joins besser.

kann das sein, das es das beo oracle garnicht gibt ?

Seit 9i gibt es auch die JOIN Sytanx.

Vorher gab es nur den Kommajoin.

Vom Ausführungsplan her sind sie aber identisch.

Dim

also grundsätzlich ist es geschmackssache, welches join du verwendest. einfacher zu schreiben / lesen finde ich persönlich das normale mit where, vor allem mit steigender komplexität. dafür ist es mehr schreibarbeit.

INNER JOIN kann bei großen datenbanken jedoch schneller arbeiten. hintergrund: übers normale join werden erst "unsichtbare" zwischentabellen erzeugt und darauf dann die bedingungen angewendet. bei großen datenbanken kann es eben entsprechend dauern, bis diese zwischentabelllen gebildet wurden. verknüpfst du dann auch noch mehrere db miteinander dauerts noch länger.

INNER JOIN hingegen wendet gleich beim erstellen der db die bedingungen an und erstellt also keine ausführliche zwischen-db und wendet dann die bedingungen an, sondern macht das quasi in einem schritt...

hoffe das war halbwegs verständlich. also im endeffekt nehm einfach das was dir besser passt, solange du nicht zwingend auf high-performance angewiesen bist.

INNER JOIN kann bei großen datenbanken jedoch schneller arbeiten. hintergrund: übers normale join werden erst "unsichtbare" zwischentabellen erzeugt und darauf dann die bedingungen angewendet. bei großen datenbanken kann es eben entsprechend dauern, bis diese zwischentabelllen gebildet wurden. verknüpfst du dann auch noch mehrere db miteinander dauerts noch länger.

INNER JOIN hingegen wendet gleich beim erstellen der db die bedingungen an und erstellt also keine ausführliche zwischen-db und wendet dann die bedingungen an, sondern macht das quasi in einem schritt...

Ich sag jetzt nicht, dass das generell falsch sein muss, aber auf jeden Fall trifft das nicht auf alle Datenbanken zu.

Unter Oracle gibt es definitiv keine Unterschiede zwischen dem Komma Join und der ANSI Syntax was den Ausführungsplan angeht.

Auch werden hier temporäre Tabellen vom Optimizer je nach Gusto angelegt oder auch nicht.

Wenn Du solche Aussagen machst, solltest Du auch immer die DB und die Version angeben.

Dim