Inner-Join/Select-Endselect/View

Aus SAP-Wiki
Wechseln zu: Navigation, Suche

Eine hitzige Diskussion entfacht sich unter Entwicklern häufig über den Streitpunkt, 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.

Ein View bietet sich an, wenn eine Datenbankabfragte über mehrere Tabellen in mehreren Programmen in gleicher oder ähnlicher Form auftritt. Dann kann der View im Select angesprochen werden und dies macht das Coding wesentlich übersichtlicher und die Netz-/Applikationslast wird in jedem Fall minimal sein. Wie beim Inner-Join (s. u.) entscheidet jedoch der Datenbankoptimizier, ob der View einen schnellen Zugriffsweg auf der Datenbank einschlägt.

Ebenso wie bei einem View wird auch auch einem "Select Inner-Join"-Befehl die Netz-/Applikationsserverbelastung maximal verringert. 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 werden massiv Daten auf dem Applikationserver transportiert.

Der Nachteil des Inner-Joins ist, wenn der Inner-Join (überraschend) keine Daten findet, weil dann nur schwer herausgefunden werden kann, wo die Ursache liegt. 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 sehr vielen Fällen entscheidet der Datenbankoptimizer richtig, aber es gibt auch Fälle, wo die Datenbank intern offensichtlich suboptimal vorgeht 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.

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.