Jede Open SQL-Anweisung bewirkt einen Transfer zwischen Applikationsserver und Datenbanksystem. Weiterhin muß für jeden Zugriff im Datenbanksystem die entsprechende Verwaltung aufgebaut bzw. wieder geöffnet werden. Es ist also günstiger, die Zugriffe der Zugriffe so klein wie möglich zu halten, um das Netzwerk und das Datenbanksystem weniger zu belasten.

Bei Datenänderungen mit INSERT, UPDATE und DELETE sollten also Mengenoperationen mit internen Tabellen statt Einzeloperationen verwendet werden. Beim Lesen von mit SELECT lohnen sich Mengenoperationen immer dann, wenn die selektierten Daten mehrmals ausgewertet werden sollen, ansonsten ist das Lesen in einer einfachen SELECT-Schleife günstiger.

Prinzipiell sollte eine bestimmte Datenmenge in einem Programm nur einmal und durch einen einzigen Zugriff übertragen werden. Ein mehrfacher Zugriff auf die gleichen Daten, z.B. ein SELECT vor einem UPDATE oder DELETE, sollte vermieden werden.

Ein einfache SELECT-Schleife ist ein einzelner Datenbankzugriff, dessen Ergebnismenge zeilenweise an das ABAP-Programm übergeben wird. Eine geschachtelte SELECT-Schleife bedeutet, daß die Anzahl der Zugriffe durch die innere Schleife mit der Anzahl der von der äußeren Schleife gelesenen Zeilen multipliziert wird. Geschachtelte SELECT-Schleifen sollten also nur dann verwendet werden, wenn die Selektion der äußeren Schleife sehr wenig Zeilen enthält.

Auf der anderen Seite ist die Zusammenführung der Daten aus verschiedenen Datenbanktabellen im relationalen Datenmodell eher die Regel als die Ausnahme. Statt geschachtelter SELECT-Schleifen können folgende Techniken eingesetzt werden:

Im ABAP Dictionary können Joins zwischen Datenbanktabellen statisch und programmübergreifend als sogenannte Views definiert werden. Solche Views können von allen ABAP-Programmen des R/3-Systems verwendet werden. Weiterhin werden Felder, die beiden Tabellen (Join Felder) gemeinsam sind, nur einmal von der Datenbank zum Applikationsserver übertragen.

Ein View im ABAP Dictionary ist als Inner Join implementiert. Werden in der inneren Tabelle keine Zeilen zu einer Zeile der äußeren Tabelle gefunden, werden keine Daten übertragen. Dies ist nicht immer erwünscht. Beim Auswerten einer Texttabelle sollen beispielsweise Zeilen in die Selektion übertragen werden, auch wenn ein Eintrag in einer bestimmten Sprache nicht vorliegt. In solchen Fällen kann ein Left Outer Join in ABAP programmiert werden.

Die Verknüpfung der Tabellen, die im View enthalten sind, wird vom Datenbanksystem vorgenommen und kann daher von diesem optimiert werden. Views können wie Datenbanktabellen auf dem Applikationsserver gepuffert werden. Bezüglich des Einsatzes der Pufferung gelten die gleichen Regeln wie bei der Pufferung von Tabellen. Sie eignet sich also hauptsächlich für Views auf die überwiegend lesend zugegriffen wird. Dadurch reduziert sich sowohl die Netzbelastung als auch die Zahl der Dateizugriffe.

In der FROM-Klausel der SELECT-Anweisung können Inner Joins und Left Outer Joins programmiert werden, um die Daten aus mehreren Datenbanktabellen in einem einzigen Datenbankzugriff zu lesen.

Joins haben allerdings den Nachteil, daß die Daten der übergeordneten Tabelle bei einer 1:N Beziehung zwischen der äußeren und inneren Tabelle redundant in der Selektion auftreten. Dies kann zu einer nicht unerheblichen Vergrößerung der an den Apllikationsserver übergebenen Datenmenge führen. Bei einem Join sollten deshalb immer nur die Spalten in der SELECT-Klausel angegeben werden, die auch wirklich benötigt werden. Weiterhin lesen Joins immer am Tabellenpuffer auf dem Applikationsserver vorbei, direkt auf der Datenbank. Deshalb sollte bei Zugriffen auf Tabellen, auf die vorwiegend lesend zugegriffen wird, ein View im ABAP Dictionary bevorzugt werden.

Die Laufzeit einer Join-Anweisung, insbesondere wenn mehr als zwei Tabellen beteiligt sind, hängt stark vom Verhalten des jeweiligen Optimizers des Datenbanksystems ab, ist aber in der Regel immer schneller als bei geschachtelten SELECT-Schleifen.

Auch die Möglichkeit in der WHERE- oder HAVING-Klausel Subqueries zu programmieren, erlaubt den Zugriff auf mehrere Datenbanktabellen in einer einzigen Open SQL-Anweisung. Die Daten einer Subquery werden erst gar nicht an den Applikationsserver übertragen, sondern zur Auswertung von Bedingungen im Datenbanksystem verwendet, wodurch komplexe Abfragen oft einfach und sehr effektiv programmiert werden können.

Man kann geschachtelte SELECT-Schleifen auch dadurch vermeiden, daß man die Selektion der äußeren Schleife in eine interne Tabelle stellt und dann die innere Schleife ein einziges mal mit dem Zusatz FOR ALL ENTRIES ausführt. Diese Technik ist ein Vorgänger von Joins in der FROM-Klausel. Auf der anderen Seite verhindert sie aber auch redundante Daten in der übertragenen Selektion.

Auch die Abtrennung der INTO-Klausel von der SELECT-Anweisung durch das Öffnen von Cursorn mit OPEN CURSOR und das zeilenweise Einlesen mit FETCH NEXT CURSOR kann dazu verwendet werden, SELECT-Schleifen zu ersetzen. Dabei muß für jede geschachtelte Schleife ein Cursor geöffnet werden. Man muß dann im Programm selbst dafür sorgen, daß die richtigen Zeilen der beteiligten Datenbanktabellen in der richtigen Reihenfolge eingelesen werden. Dies setzt in der Regel eine Fremdschlüsselbeziehung zwischen den Datenbanktabellen und deren Sortierung nach dem Fremdschlüssel voraus.