JOIN und WHERE bei vier Tabellen

[frankx]

Hellihello

ob ich das korrekt verstanden habe?

Ich nehme vier Tabellen:

produkte, kunden, rechnungen, positionen.

alle haben eine ID,

Tabelle "rechnungen" hat die Spalte Kundennummer, die die kunden.ID referenziert.
Tabelle "positionen" referenziert mit Spalte RechnungsID und ProduktID die jeweiligen rechnungen.ID und produkte.ID (die Spalte "Anzahl" sorgt dann für die Sinnhaftigkeit der Zuordung).

Nun möchte ich alle Positionen anzeigen, mit den jeweiligen Rechnungs, Kunden und Produktdaten.

Einmal mit WHERE:

SELECT
  produkte.ID AS prodID,
  kunden.ID AS kundenID,
  rechnungen.ID AS rechnID,
  rechnungen.Kundennummer AS rechnKdID,
  positionen.ID AS posID,
  positionen.RechnungsID AS posRechnID,
  positionen.ProduktID AS posProdID
  FROM
  positionen, produkte,kunden,rechnungen
  WHERE
  positionen.RechnungsID = rechnungen.ID
  AND
  rechnungen.Kundennummer = kunden.ID
  AND
  positionen.ProduktID = produkte.ID

mit JOIN:
  SELECT
  produkte.ID AS prodID,
  kunden.ID AS kundenID,
  rechnungen.ID AS rechnID,
  rechnungen.Kundennummer AS rechnKdID,
  positionen.ID AS posID,
  positionen.RechnungsID AS posRechnID,
  positionen.ProduktID AS posProdID
  FROM
  positionen
  INNER JOIN rechnungen
  ON
  (
  positionen.RechnungsID = rechnungen.ID
  )
  INNER JOIN kunden
  ON
  (
  rechnungen.Kundennummer = kunden.ID
  )
  INNER JOIN produkte
  ON
  (
  positionen.ProduktID = produkte.ID
  )

Ist eins von beidem "besser"? Ist da was falsch in dem Ansatz? Der Test hat funktioniert soweit. Gibts da noch Denkanstöße zur Herangehensweise oder Codeverbesserung oder sonstwas (abgesehen von der etwas beliebigen Variablen-Benennung). Die beiden Artikel hier unter "aktuell" auch von Vinzenz hab ich gelesen.

Dank und Gruß,

frankx

[Frank (no reg)]

Guten Abend,

Ist eins von beidem "besser"?

Was sagt dein Datenbanksystem (EXPLAIN?). Wenn du Pech hast, ja, oder auch nicht.

Ist da was falsch in dem Ansatz?

An welchem der beiden? Explizite JOIN Syntax? Ganz sicher nicht. Es ist Standard und übersichtlicher und wird von anderen Lesern wahrscheinlich eher verstanden.

Ciao, Frank

[frankx]

Hellihello

Guten Abend,

Ist eins von beidem "besser"?

Was sagt dein Datenbanksystem (EXPLAIN?). Wenn du Pech hast, ja, oder auch nicht.

Det jibbs bei phpMyAdmin irgendwo, oder?

Ist da was falsch in dem Ansatz?

An welchem der beiden? Explizite JOIN Syntax? Ganz sicher nicht. Es ist Standard und übersichtlicher und wird von anderen Lesern wahrscheinlich eher verstanden.

Also eher das JOIN, wo sich dann ein JOIN an das Ergebnis des vorherigen anlehnt, beim INNER JOIN nur dann, wenn in allen Tabellen ein Eintrag vorhanden ist, gelle?

Dank und Gruß,

frankx

[frankx]

Hellihello

Was sagt dein Datenbanksystem (EXPLAIN?). Wenn du Pech hast, ja, oder auch nicht.

Det jibbs bei phpMyAdmin irgendwo, oder?

Jau, einfach bei der SQL-Abfrage EXPLAIN voranstellen. Nur was kommt dabei raus?

Beim WHERE:

id  select_type  table  type  possible_keys  key  key_len  ref  rows  Extra
1 SIMPLE positionen ALL NULL NULL NULL NULL 5
1 SIMPLE produkte eq_ref PRIMARY PRIMARY 4 test.positionen.ProduktID 1 Using index
1 SIMPLE rechnungen eq_ref PRIMARY PRIMARY 4 test.positionen.RechnungsID 1
1 SIMPLE kunden eq_ref PRIMARY PRIMARY 4 test.rechnungen.Kundennummer 1 Using index

Beim JOIN:

id  select_type  table  type  possible_keys  key  key_len  ref  rows  Extra
1 SIMPLE positionen ALL NULL NULL NULL NULL 5
1 SIMPLE produkte eq_ref PRIMARY PRIMARY 4 test.positionen.ProduktID 1 Using index
1 SIMPLE rechnungen eq_ref PRIMARY PRIMARY 4 test.positionen.RechnungsID 1
1 SIMPLE kunden eq_ref PRIMARY PRIMARY 4 test.rechnungen.Kundennummer 1 Using index

mmh...; kein Unterschied, oder?

Dank und Gruß,

frankx

[Frank (no reg)]

mmh...; kein Unterschied, oder?

Damit wäre deine Frage beantwortet?

Du hast einfach Glück, dass MySQL im Hintergrund so klug ist, zu merken, dass es zweimal genau dasselbe ist... warum also dann nicht dasselbe machen. Die Datenbank-Maschinerie macht im Hintergrund sowieso ihr eigenes Ding. SQL wird "interpretiert".

Ciao, FF

[Vinzenz Mai]

Hallo,

Jau, einfach bei der SQL-Abfrage EXPLAIN voranstellen. Nur was kommt dabei raus?

Beim WHERE:

id  select_type  table  type  possible_keys  key  key_len  ref  rows  Extra
1 SIMPLE positionen ALL NULL NULL NULL NULL 5
1 SIMPLE produkte eq_ref PRIMARY PRIMARY 4 test.positionen.ProduktID 1 Using index
1 SIMPLE rechnungen eq_ref PRIMARY PRIMARY 4 test.positionen.RechnungsID 1
1 SIMPLE kunden eq_ref PRIMARY PRIMARY 4 test.rechnungen.Kundennummer 1 Using index

Beim JOIN:

id  select_type  table  type  possible_keys  key  key_len  ref  rows  Extra
1 SIMPLE positionen ALL NULL NULL NULL NULL 5
1 SIMPLE produkte eq_ref PRIMARY PRIMARY 4 test.positionen.ProduktID 1 Using index
1 SIMPLE rechnungen eq_ref PRIMARY PRIMARY 4 test.positionen.RechnungsID 1
1 SIMPLE kunden eq_ref PRIMARY PRIMARY 4 test.rechnungen.Kundennummer 1 Using index

mmh...; kein Unterschied, oder?

welch' ein Wunder. Erstens sollte sich "explizit" oder "implizit" nicht in der Performance niederschlagen (bei antiken MySQL-Versionen soll es mal so gewesen sein) und zweitens sollte ein Query-Optimizer so 'ne einfache Abfrage schon optimal hinkriegen können.

Freundliche Grüße

Vinzenz

[Frank (no reg)]

Hi,

den Artikel zu EXPLAIN hast du gelesen? Würde mal sagen, ganz keck, es hat weniger was mit php oder phpMyAdmin zu tun, sondern eher nur was mit MySQL.

An welchem der beiden? Explizite JOIN Syntax? Ganz sicher nicht. Es ist Standard und übersichtlicher und wird von anderen Lesern wahrscheinlich eher verstanden.

Also eher das JOIN, wo sich dann ein JOIN an das Ergebnis des vorherigen anlehnt, beim INNER JOIN nur dann, wenn in allen Tabellen ein Eintrag vorhanden ist, gelle?

Ich wiederhole mich ungern ... MySQL, Handbuch, JOIN Syntax schon mal versucht?

Cheers, Frank

[frankx]

Hellihello

Ich wiederhole mich ungern ... MySQL, Handbuch, JOIN Syntax schon mal versucht?

SELECT * FROM t1 LEFT JOIN (t2, t3, t4)
                 ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)

is equivalent to:

SELECT * FROM t1 LEFT JOIN (t2 CROSS JOIN t3 CROSS JOIN t4)
                 ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)

Will ich nur Beispiel 1 oder 2? Brauch ich denn LEFT JOIN, wenn da steht: "CROSS JOIN is a syntactic equivalent to INNER JOIN"? Zumindest intuitiv find ich es erstmal nicht. Aber wohl morgen nochmal lesen.

Dank und Gruß,

frankx

[Vinzenz Mai]

Hallo,

Ich wiederhole mich ungern ... MySQL, Handbuch, JOIN Syntax schon mal versucht?

SELECT * FROM t1 LEFT JOIN (t2, t3, t4)
                 ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)

<zitat>
    The syntax of table_factor is extended in comparison with the SQL Standard.
    The latter accepts only table_reference, not a list of them inside a pair
    of parentheses
</zitat>

Vermeide diese Syntax.

Will ich nur Beispiel 1 oder 2?

Was verstehst Du unter Beispiel 1 oder 2?

Brauch ich denn LEFT JOIN,

Du brauchst den LEFT JOIN, wenn Du einen LEFT JOIN benötigst (oder einen RIGHT JOIN). Niemand benutzt RIGHT JOINs :-)

wenn da steht: "CROSS JOIN is a syntactic equivalent to INNER JOIN"?

das ist MySQL-spezifisch. Lies Rouvens Beitrag nochmals. Was ist ein Kreuzprodukt?

Ein LEFT JOIN liefert *ganz andere* Ergebnisse als ein INNER JOIN. Lies meinen Beitrag nochmals. Lies bitte dieses Archivposting.

Freundliche Grüße

Vinzenz

[frankx]

Hellihello Vinzenz,

SELECT * FROM t1 LEFT JOIN (t2, t3, t4)
                 ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)

<zitat>
    The syntax of table_factor is extended in comparison with the SQL Standard.
    The latter accepts only table_reference, not a list of them inside a pair
    of parentheses
</zitat>

Vermeide diese Syntax.

Will ich nur Beispiel 1 oder 2?

Was verstehst Du unter Beispiel 1 oder 2?

2 war das zweite:

SELECT * FROM t1 LEFT JOIN (t2 CROSS JOIN t3 CROSS JOIN t4)
                 ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)

Du brauchst den LEFT JOIN, wenn Du einen LEFT JOIN benötigst (oder einen RIGHT JOIN). Niemand benutzt RIGHT JOINs :-)

Siehst du, woher weiß ich, dass niemand RIGHT JOINS nutzt?

wenn da steht: "CROSS JOIN is a syntactic equivalent to INNER JOIN"?

das ist MySQL-spezifisch. Lies Rouvens Beitrag nochmals. Was ist ein Kreuzprodukt?

Na, da könnte ich ja einfach erstmal den INNER JOIN nehmen (wenn das das selbe wie CROSS JOIN ist), der ja im Gegensatz zum LEFT JOIN nur Zeilen anzeigt, die gefüllte Werte enthalten.

Ein LEFT JOIN liefert *ganz andere* Ergebnisse als ein INNER JOIN. Lies meinen Beitrag nochmals. Lies bitte dieses Archivposting.

Jau, s.o., dem komm ich jetz näher.

Dank und Gruß,

frankx

[Vinzenz Mai]

Hallo,

Na, da könnte ich ja einfach erstmal den INNER JOIN nehmen (wenn das das selbe wie CROSS JOIN ist),

Nein, ein CROSS JOIN ist was ganz anderes als ein INNER JOIN - außer bei MySQL. MySQL ist ein verdammt miserables DBMS, wenn es darum geht, Grundlagen von SQL zu lernen. Nimm ein anderes, z.B. PostgreSQL oder eine Express-Edition von DB2, Oracle oder MS SQL-Server.

Freundliche Grüße

Vinzenz

[frankx]

Hellihello Vinzenz,

Nein, ein CROSS JOIN ist was ganz anderes als ein INNER JOIN - außer bei MySQL. MySQL ist ein verdammt miserables DBMS, wenn es darum geht, Grundlagen von SQL zu lernen. Nimm ein anderes, z.B. PostgreSQL oder eine Express-Edition von DB2, Oracle oder MS SQL-Server.

Mir war daran gelegen, die ersten Schritte zu gehen. Auch würde ich mich erstmal gerne auf MySQL beschränken. Mein Fazit: mit LEFT JOIN und INNER JOIN komm ich vermutlich weiter, als ich brauche.

Aber Du bestätigst mir das Gefühl von leichtem Wirrwarr, was mich bei der Sichtung der ersten Anleitungen beschlich.

Immerhin meine ich jetzt zu wissen, dass das kartesisch Produkt von

erste
a
b
c

und

zweite
d
e

als erste LEFT JOIN zweite

ad
bd
cd
ae
be
ce

und als zweite LEFT JOIN erste

ad
ae
bd
be
cd
ce

ergibt, und die ON - Bedingung dieses Ergebnis dann filtert. Das würde mir für den Anfang reichen, im Hinterkopf, dass ich das alles auch mit WHERE erreichen könnte, das aber deprecated Syntax ist.

Dank und Gruß,

Robert aka

frankx

[Vinzenz Mai]

Hallo,

Aber Du bestätigst mir das Gefühl von leichtem Wirrwarr, was mich bei der Sichtung der ersten Anleitungen beschlich.

Immerhin meine ich jetzt zu wissen, dass das kartesisch Produkt von

erste
a
b
c

und

zweite
d
e

miserable Beispiele. Rouven hat doch ganz ordentliche im Angebot, die man nachvollziehen kann. Hier geht nichts mit Nachvollziehen. Kurz: Diese Beispieltabellen taugen nichts. Es fehlen Spaltennamen. Diese sind hier essentiell.

als erste LEFT JOIN zweite

Nein, hier begehst Du bereits einen Fehler. Da gibt es keinen LEFT JOIN.
Nein, nicht. Wirklich nicht.

Das kartesische Produkt der beiden Tabellen ergibt sich als

*CROSS JOIN*

und nichts anderes. CROSS JOIN, nicht LEFT JOIN, nicht INNER JOIN!
zu

a d
b d
c d
a e
b e
c e

die Leerzeichen als Spaltentrenner sind notwendig.

und als zweite LEFT JOIN erste

Auch hier wieder CROSS JOIN.

a d
a e
b d
b e
c d
c e

Deine zweite Ergebnismenge ist zur ersten äquivalent. Ein JOIN macht keine Aussage über die Anordnung der Datensätze in der Ergebnismenge. Eine ORDER-BY-Klausel kann zu den zwei verschiedenen Reihenfolgen führen, ansonsten ist die Reihenfolge der Datensätze zufällig - und jede beliebige Reihenfolge ist ein gültiges Ergebnis.

ergibt, und die ON - Bedingung dieses Ergebnis dann filtert.

Jein. Ein LEFT JOIN oder ein INNER JOIN ohne Join-Bedingung ist nicht sinnvoll. Dann willst Du einen CROSS JOIN.

Ein INNER JOIN oder ein LEFT JOIN mit Deinen Beispieldaten ist ebenfalls wenig sinnvoll, da die beiden Tabellen keine besonders sinnvolle Verknüpfung zulassen. Nimm anständige Beispieltabellen. Sonst fällt das Verständnis verdammt schwer.

Das würde mir für den Anfang reichen, im Hinterkopf, dass ich das alles auch mit WHERE erreichen könnte, das aber deprecated Syntax ist.

Nein, Du kannst nicht alles mit WHERE erreichen (es sei denn, das DBMS bietet eine proprietäre Syntax für OUTER JOINs über die WHERE-Klausel wie z.B. Oracle oder MS SQL-Server).

Ich hatte Dir dazu gestern den Link zu einem Beispiel gepostet. Es ist ein Riesenunterschied zwischen einem INNER JOIN und einem LEFT JOIN. Es kann einen Riesenunterschied ausmachen, ob Du ein Filterkriterium bei einem LEFT JOIN in der WHERE-Klausel oder in der Join-Bedingung hast:

Beispiel mit Erläuterungen: </archiv/2008/4/t170482/#m1114517>

Freundliche Grüße

Vinzenz

[frankx]

Hellihello Vinzenz,

Das kartesische Produkt der beiden Tabellen ergibt sich als

*CROSS JOIN*

und nichts anderes. CROSS JOIN, nicht LEFT JOIN, nicht INNER JOIN!

Es sei denn, ihnen wären keine Bedingungen mitgegeben?

Nein, Du kannst nicht alles mit WHERE erreichen (es sei denn, das DBMS bietet eine proprietäre Syntax für OUTER JOINs über die WHERE-Klausel wie z.B. Oracle oder MS SQL-Server).

Aha. Einen Teil konnte man, aber gut zu wissen, dass nicht alles geht.

Beispiel mit Erläuterungen: /archiv/2008/4/t170482/#m1114517

Darin:

liefert wegen der speziellen Behandlung von NULL-Werten bei Vergleichen nur folgende Datensätze zurück, die Gremien, denen die Person mit der id 10 angehört:

id | bezeichnung | id_person
----------------------------
 1 | Spiel       | 10
 3 | Jugend      | 10

Führst Du jedoch die Einschränkung auf die Person mit der id 10 in der Join-Bedingung auf, so erhältst Du alle Gremien:

Wieso hebt das AND die Null-Zeilen nicht auf, das WHERE aber wohl? Sind die beim "WHERE" schon "weg"? Oder fliegen die durch das WHERE raus? Ich vermutete jetzt, dass erstmal nur INNER JOIN eine Art Schnittmenge bzw. Teilmenge mit dem Zusatz: "ohne Leere Elemente" liefert.

Dank und Gruß,

frankx

[Vinzenz Mai]

Hallo,

Das kartesische Produkt der beiden Tabellen ergibt sich als

*CROSS JOIN*

und nichts anderes. CROSS JOIN, nicht LEFT JOIN, nicht INNER JOIN!

Es sei denn, ihnen wären keine Bedingungen mitgegeben?

Nein, ein OUTER JOIN ohne Bedingung ist sinnlos.
Ein INNER JOIN ohne Bedingung ebenfalls.
Dann willst Du einen CROSS JOIN.

Dann schreibe auch CROSS JOIN und betreibe keinen Etikettenschwindel.

Nein, Du kannst nicht alles mit WHERE erreichen (es sei denn, das DBMS bietet eine proprietäre Syntax für OUTER JOINs über die WHERE-Klausel wie z.B. Oracle oder MS SQL-Server).

Aha. Einen Teil konnte man, aber gut zu wissen, dass nicht alles geht.

Einen INNER JOIN kannst Du stets implizit schreiben, wie Du in Rouvens Artikel nachlesen kannst. Ich bevorzuge wegen der Klarheit, Einfachheit und geringeren Fehleranfälligkeit die explizite Join-Syntax, die bereits seit ca. 10 Jahren (und mehr) von allen (jetzt) relevanten DBMS unterstützt wird.

Beispiel mit Erläuterungen: /archiv/2008/4/t170482/#m1114517

liefert wegen der speziellen Behandlung von NULL-Werten bei Vergleichen nur folgende Datensätze zurück, die Gremien, denen die Person mit der id 10 angehört:

id | bezeichnung | id_person

1 | Spiel       | 10
3 | Jugend      | 10

Führst Du jedoch die Einschränkung auf die Person mit der id 10 in der Join-Bedingung auf, so erhältst Du alle Gremien:

Wieso hebt das AND die Null-Zeilen nicht auf, das WHERE aber wohl? Sind die beim "WHERE" schon "weg"?

Ja: Der Vergleich NULL = 10 liefert false
    Der Vergleich NULL = NULL übrigens auch.

Oder fliegen die durch das WHERE raus? Ich vermutete jetzt, dass erstmal nur INNER JOIN eine Art Schnittmenge bzw. Teilmenge mit dem Zusatz: "ohne Leere Elemente" liefert.

Der INNER JOIN liefert genau die Datensätze beider beteiligten Tabellen, die die Bedingung erfüllen, keine anderen.

Ein OUTER JOIN liefert *alle* Datensätze der einen Tabelle, auch wenn es für diese keine Entsprechungen gemäß der Join-Bedingung in der zweiten Tabelle gibt. Spalten, die aus der zweiten Tabelle stammen, haben dann den Wert NULL.

Deswegen ist doch ein OUTER JOIN *ohne* Joinbedingung so völlig sinnfrei. Dann willst Du keinen OUTER JOIN und dann schreibst Du auch nicht OUTER JOIN dran. Auf einen Briefumschlag, der nur in ein anderes Stadtviertel soll, schreibst Du ja auch nicht AIRMAIL drauf.

Zurück zum Beispiel:
Die WHERE-Klausel filtert aus der Ergebnismenge die gewünschten Datensätze heraus, d.h. diejenigen, für die die WHERE-Bedingung zutrifft. Daher fliegen die beiden Datensätze mit

id_person = NULL

heraus.

Die JOIN-Bedingung dient jedoch zur Ermittlung der Ergebnismenge. Daher enthält die Ergebnismenge alle Datensätze aus der Gremientabelle. Gibt es keine Datensätze in der mitglieder-Tabelle, die der JOIN-Bedingung entsprechen so enthalten alle Spalten der Ergebnismenge, die aus der mitglieder-Tabelle stammen, für diese Datensätze den NULL-Wert - weil wir einen OUTER JOIN verwendet haben. Deswegen hat nach Verschiebung der Bedingung, um welche Person es sich handelt, aus der WHERE-Klausel in die JOIN-Bedingung einen dramatischen Effekt auf das Ergebnis der Abfrage.

Spezialfälle sind gut und schön, beim Erlernen der Grundlagen jedoch nur hinderlich. Du beschäftigst Dich Stunden mit nichtvorhandenen Problemen. Hast Du jedoch die Grundlagen verstanden, so sind die Spezialfälle gleich mit erledigt.

Das Schlimme an diesen meinen Ausführungen ist, dass das alles in Rouvens und meinem Artikel drinsteht - die Du doch gelesen hast.

Freundliche Grüße

Vinzenz

[frankx]

Hellihello Vinzenz,

Das kartesische Produkt der beiden Tabellen ergibt sich als

*CROSS JOIN*

und nichts anderes. CROSS JOIN, nicht LEFT JOIN, nicht INNER JOIN!

Oder FULL OUTER JOIN, wenn ich Rouven recht verstehe:

"Der FULL OUTER JOIN kommt dem ursprünglichen Kreuzprodukt von allen Joins am nächsten. Er ist gewissermaßen die Kombination aus LEFT und RIGHT-JOIN."

Dann schreibe auch CROSS JOIN und betreibe keinen Etikettenschwindel.

Jau, natürlich: Nur wenn das auch anders geht und beschrieben wird, wolltich kapieren, warum das auch anders geht.

Einen INNER JOIN kannst Du stets implizit schreiben, wie Du in Rouvens Artikel nachlesen kannst.

Jap.
"In der Regel sollen für den Join Kriterien festgelegt werden (siehe z.B. Equi-Join weiter oben). Grundsätzlich besteht die Möglichkeit, diese Kriterien im Bereich der WHERE-Klausel einer Abfrage anzugeben.

SELECT c FROM X, Y WHERE X.a = Y.a AND X.b = Y.b

Im Fall der impliziten Schreibweise müssen die Kriterien hier platziert werden, bei der expliziten können sie so platziert werden."

Ich bevorzuge wegen der Klarheit, Einfachheit und geringeren Fehleranfälligkeit die explizite Join-Syntax, die bereits seit ca. 10 Jahren (und mehr) von allen (jetzt) relevanten DBMS unterstützt wird.

Ich auch (;-).

Das Schlimme an diesen meinen Ausführungen ist, dass das alles in Rouvens und meinem Artikel drinsteht - die Du doch gelesen hast.

Jau, ich las: "Die LEFT JOIN- bzw. RIGHT JOIN-Varianten sind auf den ersten Blick etwas schwieriger zu verstehen."

Stimmt (;-)! Auch auf den zweiten Blick, also der dann natürlich auf dem Ersten. Ich denke, jetzt hab ichs, bzw. bin auch in der Lage, weitere Details der detailgetreuen Anleitung zu kapieren. Immerhin aber erscheinen im Dialog ja dann doch die Fakten nochmal in neugewürfeltem Kontext, will sagen, die Aussage: "Das steht alles in den beiden Artikeln" mag stimmt im Sinne von: "Diese Sachverhalte werden dort erklärt", nicht aber im Sinne von, dass die Erklärungen/Zusammenstellung dieselbe ist. Vielleicht gibts ja mal einen Artikel, wie man was kapiert (Erkenntnistheorie) und vielleicht steht da ja auch drin, dass da die Kommunikation und das trial and error/success eine Rolle spielt.

Dank und Gruß,

Robert

frankx

[Ilja]

yo,

Das kartesische Produkt der beiden Tabellen ergibt sich als

*CROSS JOIN*

und nichts anderes. CROSS JOIN, nicht LEFT JOIN, nicht INNER JOIN!

Oder FULL OUTER JOIN, wenn ich Rouven recht verstehe:

dann hast du es falsch verstanden FULL OUTER JOIN ist kein CROSS JOIN, ganz und gar nicht.

Ilja

[frankx]

Hellihello auchyo,

Das kartesische Produkt der beiden Tabellen ergibt sich als

*CROSS JOIN*

und nichts anderes. CROSS JOIN, nicht LEFT JOIN, nicht INNER JOIN!

Oder FULL OUTER JOIN, wenn ich Rouven recht verstehe:

dann hast du es falsch verstanden FULL OUTER JOIN ist kein CROSS JOIN, ganz und gar nicht.

Wie ist denn dieses Rouven-Zitat zu verstehen?

"Der FULL OUTER JOIN kommt dem ursprünglichen Kreuzprodukt von allen Joins am nächsten. Er ist gewissermaßen die Kombination aus LEFT und RIGHT-JOIN"

Das ist nicht das kartesische Produkt? CROSS JOIN ist das kartesische Produkt?

Dank und Gruß,

frankx

[Vinzenz Mai]

Hallo,

Wie ist denn dieses Rouven-Zitat zu verstehen?

"Der FULL OUTER JOIN kommt dem ursprünglichen Kreuzprodukt von allen Joins am nächsten.

am nächsten. Nur am nächsten. Nicht mehr. Es ist nicht das Gleiche.

Er ist gewissermaßen die Kombination aus LEFT und RIGHT-JOIN"

wie ich Dir bereits anhand der Umsetzung mittels UNION zeigte

Das ist nicht das kartesische Produkt?

Ja, FULL OUTER JOIN ist nicht das kartesische Produkt.

CROSS JOIN ist das kartesische Produkt?

Ja, CROSS JOIN ist das kartesische Produkt.

Den impliziten CROSS JOIN bekommst Du übrigens über den Komma-Operator

  
SELECT  
    a.*,    -- * nur für Demozwecke!  
    b.*  
FROM  
    a,  
    b  

ist äquivalent zu

  
SELECT  
    a.*,    -- * nur für Demozwecke!  
    b.*  
FROM  
    a  
CROSS JOIN  
    b  

und hat nichts mit

  
SELECT  
    a.*,    -- * nur für Demozwecke!  
    b.*  
FROM  
    a  
FULL OUTER JOIN  
    b  
ON  
    <join-bedingung>  

zu tun.

Am besten nimmst Du Dir einen netten Client mit einer GUI wie z.B. den MySQL-Query-Browser, legst Dir ein paar Tabellen an und schaust Dir die Ergebnisse verschiedener (aber ähnlicher) Queries an. Vollziehe die Beispiele von Rouven und mir nach.

Freundliche Grüße

Vinzenz

[Ilja]

yo,

Wie ist denn dieses Rouven-Zitat zu verstehen?

"Der FULL OUTER JOIN kommt dem ursprünglichen Kreuzprodukt von allen Joins am nächsten. Er ist gewissermaßen die Kombination aus LEFT und RIGHT-JOIN"

ich hätte diesen absatz wegeglassen, CROSS JOIN und FULL OUTER JOIN haben nach meiner ansicht nicht wirklich viel gemeinsam, sie tun beide andere dinge und sind entsprechent der aufgaben einzusetzen. also verbeis dich nicht in diese aussage, versuche lieber zu verstehen, was ein CORSS JOIN macht und was ein FULL OUTER JOIN. Vinzenz hat dir dafür schon viele hinweise zum verstehen gegeben.

Ilja

[Vinzenz Mai]

Hallo Robert,

Immerhin aber erscheinen im Dialog ja dann doch die Fakten nochmal in neugewürfeltem Kontext, will sagen, die Aussage: "Das steht alles in den beiden Artikeln" mag stimmt im Sinne von: "Diese Sachverhalte werden dort erklärt", nicht aber im Sinne von, dass die Erklärungen/Zusammenstellung dieselbe ist.

wenn es irgendwo vom Verständnis hakt, wäre ich Dir für eine Rückmeldung dankbar. Mein Artikel ist zwar seit über zwei Jahren unverändert, aber das heißt nicht, dass er nicht verbessert werden kann. Für den Autor ist es oft sehr schwer nachzuvollziehen, wo der Leser hängenbleibt, wo ein zu großer Sprung ist, wo etwas nicht exakt genug erklärt ist, ...

Freundliche Grüße

Vinzenz

[frankx]

Hellihello Vinzenz,

wenn es irgendwo vom Verständnis hakt, wäre ich Dir für eine Rückmeldung dankbar. Mein Artikel ist zwar seit über zwei Jahren unverändert, aber das heißt nicht, dass er nicht verbessert werden kann. Für den Autor ist es oft sehr schwer nachzuvollziehen, wo der Leser hängenbleibt, wo ein zu großer Sprung ist, wo etwas nicht exakt genug erklärt ist, ...

Jau, würde das morgen bei frischerem Verstand vielleicht auch das im Hinterkopf nochmal durchgehen.

Dank und Gruß,

Robert aka

frankx

[Vinzenz Mai]

Hallo,

Was sagt dein Datenbanksystem (EXPLAIN?). Wenn du Pech hast, ja, oder auch nicht.
Det jibbs bei phpMyAdmin irgendwo, oder?

Bestimmt. Da ich phpMyAdmin so gut wie nie nutze, kann ich Dir das nicht sagen.
Es gibt aber was darüber im MySQL-Handbuch:
http://dev.mysql.com/doc/refman/5.0/en/explain.html
http://dev.mysql.com/doc/refman/5.0/en/using-explain.html

und verdammt viele Postings im hiesigen Archiv.

Ist da was falsch in dem Ansatz?

An welchem der beiden? Explizite JOIN Syntax? Ganz sicher nicht. Es ist Standard und übersichtlicher und wird von anderen Lesern wahrscheinlich eher verstanden.

Also eher das JOIN, wo sich dann ein JOIN an das Ergebnis des vorherigen anlehnt, beim INNER JOIN nur dann, wenn in allen Tabellen ein Eintrag vorhanden ist, gelle?

Was meinst Du damit?

Explizite Join-Syntax ist übersichtlicher, leichter zu lesen und vermeidet Fehler [1] - und bei Outer Joins möchtest Du nicht die proprietäre Syntax Deines DBMS lernen, so denn eine existiert.

[1] dazu gibt es mindestens einen Thread in der aktuellen Forumshauptdatei.

Freundliche Grüße

Vinzenz

[frankx]

Hellihello Vinzenz,

Explizite Join-Syntax ist übersichtlicher, leichter zu lesen und vermeidet Fehler [1] - und bei Outer Joins möchtest Du nicht die proprietäre Syntax Deines DBMS lernen, so denn eine existiert.

[1] dazu gibt es mindestens einen Thread in der aktuellen Forumshauptdatei.

Nee, OUTER JOINS will ich nicht, lieber garkeine.

Dank und Gruß,

frankx

[Vinzenz Mai]

Hallo,

Explizite Join-Syntax ist übersichtlicher, leichter zu lesen und vermeidet Fehler [1] - und bei Outer Joins möchtest Du nicht die proprietäre Syntax Deines DBMS lernen, so denn eine existiert.

[1] dazu gibt es mindestens einen Thread in der aktuellen Forumshauptdatei.

Nee, OUTER JOINS will ich nicht, lieber garkeine.

OUTER JOINs sind tägliches Brot, meist in Form eines LEFT JOIN. OUTER ist normalerweise optional und wird daher üblicherweise weggelassen, sprich statt LEFT JOIN kann man auch LEFT OUTER JOIN schreiben.

Da

SELECT  
    spaltenliste  
FROM  
    a  
RIGHT JOIN  
    b  
ON  
    join-bedingung

äquivalent ist zu

SELECT  
    spaltenliste  
FROM  
    b  
LEFT JOIN  
    a  
ON  
    join-bedingung

nutzt übrigens so gut wie niemand RIGHT JOINs, selbst wenn diese vom DBMS implementiert sind (in vielen Fällen schreibt der Optimierer im einem ersten Schritt die RIGHT JOINs zu LEFT JOINs um :-)).

Daneben gibt es noch den FULL OUTER JOIN. Sollte dieser nicht implementiert sein (wie z.B. bei MySQL), so kann man diesen am einfachsten über

  
SELECT  
    spaltenliste  
FROM  
    b  
LEFT JOIN  
    a  
ON  
    join-bedingung  
UNION  
SELECT  
    spaltenliste  
FROM  
    a  
LEFT JOIN  
    b  
ON  
    join-bedingung  

Es sei denn, man verwendet eine 3er-Version von MySQL, die neben vielen anderen hochinteressanten und wichtigen Sachen noch nicht mal UNION beherrscht. Von einem Provider, der in punkto MySQL sowas antiquiertes anbietet, sollte man allerdings Abstand halten. Derzeit hat es eine Produktionsversion aus der 5.0er-Serie zu sein. 5.1 ist erst ein Release-Candidate und sollte produktiv noch nicht genutzt werden.

Freundliche Grüße

Vinzenz

[frankx]

Hellihello Vinzenz,

merci, such a knackige kurzzusammenfassung find ich den genannten artikeln irgendwie nicht, auch wenn einr von dir stammt. aber war gestern ja auch schon spät.

Dank und Gruß,

Robert aka

frankx