*Markus: (SQL) Welche SELECT-Anweisung am "besten"?

Hallo,

ich will aus 3 Tabellen die Lehrer ausgeben, die am Montag unterricht haben, inkl. deren Vorgesetzten. Das könnte ich auf 3 verschiedene Varianten lösen:

  
SELECT DISTINCT L_NAME, V_ART  
FROM Vorgesetzte  
INNER JOIN (Lehrer  
    INNER JOIN Stunden  
    ON Stunden.ST_L_Lehrer = Lehrer.L_ID)  
ON Lehrer.L_L_CHEF = Vorgesetzte.V_L_VORG  
WHERE Stunden.ST_STUNDE LIKE 'MO%';  
  
SELECT DISTINCT L_NAME, V_ART  
FROM Stunden  
INNER JOIN (Lehrer  
     INNER JOIN Vorgesetzte  
     ON Lehrer.L_L_CHEF = Vorgesetzte.V_L_VORG)  
ON Stunden.ST_L_LEHRER = Lehrer.L_ID  
WHERE Stunden.ST_STUNDE LIKE 'MO%';  
  
SELECT DISTINCT L_NAME, V_ART  
FROM Stunden, Lehrer, Vorgesetzte  
WHERE Lehrer.L_L_CHEF = Vorgesetzte.V_L_VORG  
AND Stunden.ST_L_LEHRER = Lehrer.L_ID  
AND Stunden.ST_STUNDE LIKE 'MO%';  

Alle 3 Anweisungen machen das selbe, aber zumindest die letzte Anweisung sollte entweder effizienter oder weniger effizient als als oberen 3 sein. Welche Vorgehensweise ist stets am besten geeignet? Mit JOINs zu arbeiten, oder mit der Aneinanderreihung wie im letzten Beispiel?
Es ist mir natürlich klar, dass das letzte Beispiel kein LEFT oder RIGHT JOIN zulässt, sondern immer nur ein INNER JOIN simuliert.

Markus

  1. Hallo Markus,

    ich will aus 3 Tabellen die Lehrer ausgeben, die am Montag unterricht haben, inkl. deren Vorgesetzten. Das könnte ich auf 3 verschiedene Varianten lösen:

    Alle 3 Anweisungen machen das selbe, aber zumindest die letzte Anweisung sollte entweder effizienter oder weniger effizient als als oberen 3 sein.

    warum sollte das so sein?

    Welche Vorgehensweise ist stets am besten geeignet?

    Darauf gibt es keine Antwort. Dafür sorgt allein das Wort "stets".

    Mit JOINs zu arbeiten, oder mit der Aneinanderreihung wie im letzten Beispiel?

    Implizite Joins. Ich mag sie nicht, ich verliere die Übersicht. Ich mag
    explizite Joinsyntax. Das ist meine persönliche Vorliebe. Es bleiben dennoch
    Joins. Bei MySQL sollen explizite Joins mal schneller abgearbeitet worden
    sein. Das ist aber meines Wissens vorbei.

    Es ist mir natürlich klar, dass das letzte Beispiel kein LEFT oder RIGHT JOIN zulässt, sondern immer nur ein INNER JOIN simuliert.

    Diverse SQL-Dialekte wie die des MS SQL Server oder von Oracle unterstützen
    auch implizite OUTER JOINs mit proprietärer Syntax.

    Denke daran, dass das DBMS einen Optimierer besitzt, der Dein Statement
    eventuell umschreibt, dass Du Dir den Aufwand anschauen kannst, den Deine
    Anweisung verursacht. Schau es Dir an, pack genügend Daten in Deine Tabellen.
    Erstelle ggf. fehlende Indexe.

    Freundliche Grüße

    Vinzenz

    1. Hallo,

      ok, danke für deine Antwort. Also mit anderen Worten ist es meistens nur eine Geschmackssache, wie man den Ausdruck verfasst. Ich muss aber zugeben, dass mir implizite Joins etwas leichter fallen.

      Markus

      1. yo.

        ok, danke für deine Antwort. Also mit anderen Worten ist es meistens nur eine Geschmackssache, wie man den Ausdruck verfasst.

        nein, auf keine fall, wie anweisungen formuliert werden kann einen sehr grossen unterschied in der ausführung bringen auch wenn das gleiche ergebniss raus kommt.

        was die lesbarkeit betrifft, so ist das zum teil sicherlich geschmackssache, aber eben nur zum teil. ich stimmt Vinz zu, dass explizite Joins besser zu lesen sind.

        Ilja

        1. Moin Moin!

          ok, danke für deine Antwort. Also mit anderen Worten ist es meistens nur eine Geschmackssache, wie man den Ausdruck verfasst.

          nein, auf keine fall, wie anweisungen formuliert werden kann einen sehr grossen unterschied in der ausführung bringen auch wenn das gleiche ergebniss raus kommt.

          Deswegen gibt es SQL-Kommandos wie "explain", die -- zusammen mit der DB-Dokumentation -- halbwegs verständlich erklären, wie die DB das auf "explain" folgende Kommando verstanden hat und auszuführen gedenkt. Damit kann man schonmal gröbere Probleme (Full Table Scan etc.) sehen.

          Und schließlich und endlich kann man auch mal einen Benchmark laufen lassen, sprich: Produktivdaten in eine Test-Datenbank packen, Zeit für 1000x SQL-Statement A messen, Zeit für 1000x SQL-Statement B messen, Zeit für 1000x SQL-Statement C messen. Das SQL-Statement mit der geringsten Zeit gewinnt.

          Infos zu Explain:
          mysql 5.0
          PostgreSQL 8.2 Using Explain
          Oracle

          Alexander

          --
          Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".