(SQL) Welche SELECT-Anweisung am "besten"?
*Markus
- sonstiges
0 Vinzenz Mai
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
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
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
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
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