Select Inner-Join, Select-Endselect oder View
Siehe Schlüsselbefehl Select.
Eine hitzige Diskussion entfacht sich gelegentlich unter Entwicklern über die Frage, ob die Selektion von mehreren Tabellen mit dem "Select Inner Join", mit einem geschachtelten "Select - Endselect"-Befehl oder mit einem View vorgenommen werden sollte.
Eine eindeutige Antwort darauf kann es nicht geben.
Welche Variante die höchste Performance hat, kann oft nur durch Messen und Probieren herausgefunden werden. Im Zweifel spricht aufgrund der Kürze und Übersichtlichkeit des Codings einiges für den Inner-Join.
Ein View bietet sich an, wenn eine Datenbankabfragte über mehrere Tabellen in mehreren Programmen in gleicher oder ähnlicher Form auftritt. Es kann jedoch etwas schwer verständlich sein, wenn die Datenbankabfrage erst durch die Analyse des Views ersichtlich wird.
Oft wird ein Inner-Join gegenüber Select-Endselect und Views am übersichtlichsten sein und der Datenbankoptimizer kann dynamisch den schnellsten Weg bestimmen, in welcher Reihenfolge die Datenbanktabellen abgefragt werden. Meist wird der Datenbankoptimizer den schnellsten Weg finden.
Vorteil Inner-Join
- Bei einem "Select Inner-Join"-Befehl die Netz-/Applikationsserverbelastung minimiert.
- Der Vorteil des Inner-Joins ist dessen Übersichtlichkeit. Innerhalb weniger Zeilen Code können mehrere Tabellen eingelesen werden, samt der Where-Bedingung und der Verknüpfung der Tabellen.
- Der geschachtelte Select-Endselect-Befehl kann dagegen extrem schwer lesbar sein und es entsteht mehr Datenverkehr zwischen Datenbank und Applikationsserver.
Nachteil Inner-Join
- Wenn der Inner-Join (überraschend) keine Daten findet, ist es schwer die Ursache zu finden. Der Inner-Join kann nur als 1 Schritt debuggt werden. Man geht dann normal die Where-Bedingungen und die Joins durch und überprüft mit SE16/SE16N, ob hier Daten gefunden werden. Das kann mühsam und zeitraubend sein.
- Der Inner-Join- Befehl kann nicht in Einzelschritten debuggt werden. Hier ist der geschachtelte Select-Endselect-Befehl durch die Möglichkeit der Abfrage des sy-subrc bei den Einzelschritten überlegen.
- Beim Inner-Join kann auch problematisch sein, wenn viele Where- Bedingungen gefüllt sind und viele Verknüpfungen zwischen Tabellen vorliegen. Dann muss der Datenbankoptimizer entscheiden, was der optimale Zugriffspfad auf der Datenbank ist. In den meisten Fällen entscheidet der Datenbankoptimizer richtig, aber es gibt auch Konstellationen, wo die Datenbank eine nicht optimale Datenbankselektionsreihenfolge durchführt und eine kluge Anlage des Select-Endselects wesentlich performanter sein kann. In solchen Fällen hilft häufig der Trick im Inner-Join, bestimmte Where- Bedingungen aus dem Inner-Join herauszulösen und erst nach dem Inner-Join abzufragen. So läuft der Datenbankoptimizier nicht in die Falle, die falsche Strategie einzuschlagen und die Performance kann massiv steigen.
Left outer join / left join
- Bei einem Inner Join zwischen dbtab1 und dbtab2 wird nur die Schnittmenge zwischen beiden Tabellen zurückgegeben.
- Bei einem "Left outer join" (bzw. "left join") werden alle Daten von der linken Tabellenseite zurückgegeben, auch wenn es keine Schnittmenge zu dbtab2 gibt. Dann wird die dbtab2 initial zurückgegeben.
- Ein Beispiel wäre, wenn man die Kundenaufträge selektieren möchte (VBAK) und einen bestimmten Partner (VBAP-PARVW = ZA), der aber nicht in jedem Kundenauftrag vorhanden ist.
- Findet er bei der mit left outer join /left join verknüpften Tabelle keinen passenden Datensatz von VBPA, wird ein Select-Feld (hier Vbpa~Kunnr) mit dem Initialwert gefüllt.
Select Vbak~Vbeln Vbpa~Kunnr Into @data(lt_itab) From vbak Left outer join vbpa On vbpa~Vbeln = vbak~Vbeln And vbpa~Parvw = 'ZA'.
Das ist das gleiche Coding bei der Ersetzung von "left outer join" in "left join"
Select Vbak~Vbeln Vbpa~Kunnr Into @data(lt_itab) From vbak Left join vbpa On vbpa~Vbeln = vbak~Vbeln And vbpa~Parvw = 'ZA'.
Ob hier VBPA auf der rechten oder linken Seite steht, spielt keine Rolle.
