ABAP - Performance für den SELECT
In diesem Artikel schauen wir uns noch ein paar Spezialfälle mit dem SELECT an und beleuchten die Performance dieser Konstrukte. Wir zeigen dir die aktuellen Alternativen dafür und geben kleinere Tipps beim Lesen.
Inhaltsverzeichnis
Bereits in einem älteren Artikel haben wir dir den neuen SELECT vorgestellt und was die Vorteile sind mit der Inline-Deklaration zu arbeiten. In diesem Artikel wollen wir etwas auf die Spezialfälle eingehen und was mittlerweile nicht mehr so angesagt oder performant ist.
Aufbau
Für die gezeigten Beispiele verwenden wir die Tabelle T001, welche die Buchungskreise im System darstellt und vor allem im Bereich Finanzen zum Tragen kommt. Dazu haben wir eine eigene Tabelle angelegt, welche einige der Felder aus der T001 und ein eigenes Feld bekommt.
SELECT ... ENDSELECT
Auch als Select-Schleife bezeichnet, handelt es sich hierbei um einen SELECT der die Datensätze als Paket oder Einzelsatz holt und den Anweisungen zwischen SELECT und ENDSELECT zur Verfügung stellt. Dabei wird für jedes Paket die Datenbankschnittstelle angesprochen. Schauen wir uns dazu einmal ein Beispiel um, bei dem wir Datensätze von der Datenbank lesen, aufbereiten und in einer internen Tabelle zur Verfügung stellen.
DATA:
lt_company_code TYPE STANDARD TABLE OF z60bs_db_ccodes,
ls_company_code TYPE zbs_db_ccodes.
SELECT *
FROM t001
WHERE land1 = 'DE'
INTO @DATA(ls_database).
ls_company_code = CORRESPONDING #( ls_database ).
ls_company_code-settings = ls_database-bukrs && ` ` && ls_database-waers.
IF ls_database-bukrs_glob IS NOT INITIAL.
ls_company_code-bukrs = ls_database-bukrs_glob.
ENDIF.
INSERT ls_company_code INTO TABLE lt_company_code.
ENDSELECT.
Im S/4 HANA Umfeld sind solche Schleifen extrem langsam und deine Software würde am Ende länger laufen. Hierfür wurde in der Vergangenheit die gesamten Daten mit einem Zugriff von der Datenbank gelesen und dann per Loop die einzelnen Datensätze angepasst. Mittlerweile solltest du sogar per Code-Pushdown die meisten Operationen der Datenbank überlassen. In diesem Fall sieht das Statement am Ende so aus:
SELECT coalesce( bukrs_glob, bukrs ) AS bukrs, butxt, land1, waers, concat_with_space( bukrs, waers, 1 ) AS settings
FROM t001
WHERE land1 = 'DE'
INTO TABLE @DATA(lt_company_code_new).
Wie du ganz leicht erkennst, ist nicht mehr viel von dem ursprünglichen Konstrukt übrig und das Coding ist auf ein SELECT Statement zusammengeschmolzen, da wir alles damit machen können, was wir oben benötigten. Damit entlasten wir den ABAP Stack und lassen unsere performante HANA Datenbank arbeiten.
Hinweis: Der Code-Pushdown oder die Anlage eines CDS Views sind erst richtig performant, wenn eine HANA Datenbank verwendet wird. In Systemen ohne HANA Datenbank, können diese Konstrukte sogar langsamer als der alte Weg werden.
INSERT FROM SELECT
Du möchtest Daten von einer mehrerer Tabelle zusammenführen und in eine neue Tabelle einfügen? Dafür waren früher mehrere Schritte nötig und die Daten mussten vorher auf den Applikationsserv geladen werden, was Zeit und Performance kostete. Dazu das folgende kleine Beispiel bei dem wir die Daten aus den Buchungskreisen in eine eigene Tabelle laden möchten.
DATA:
lt_company_codes TYPE STANDARD TABLE OF zbs_db_ccodes.
SELECT mandt, bukrs, butxt, land1, waers, ' ' AS settings
FROM t001
WHERE land1 = 'DE'
INTO CORRESPONDING FIELDS OF TABLE @lt_company_codes.
INSERT zbs_db_ccodes FROM TABLE @lt_company_codes.
Beim ersten Select werden alle Buchungskreisdaten in die Tabelle im Report geladen, was Performanceverlust für die Datenbankschnittstelle bedeutet. Beim Einfügen der Daten in die Tabelle geht dann weitere Performance verloren, weil die Datenzurück auf die Datenbank geladen werden müssen. Hier kann man sich etwas Zeit und Kosten sparen und die Daten direkt von der einen in die anderen Tabelle laden, ohne über die Datenbankschnittstelle zu müssen.
INSERT zbs_db_ccodes FROM (
SELECT bukrs, butxt, land1, waers
FROM t001
WHERE land1 = 'DE'
).
Als Quelle für den Insert, wird direkt der Select verwendet, der die Daten bereitstellt. Hierbei könnte es sich auch um einen Join über mehrere Tabellen handeln, der Einfachheithalber haben wir einen kleinen Select verwendet.
S/4 HANA
Im Umfeld von S/4 HANA und bei der Verwendung der HANA Datenbank, solltest du immer darauf achten performant von der Datenbank zu lesen und möglichst auf die Wildcard * zu verzichten. Operationen die du später im Programm durchführen möchtest, kannst du bereit auf der Datenbank durchführen lassen. Möchtest du solche Logiken und Views wiederverwenden, solltest du diese über einen Core Data Service abbilden.
Fazit
Der neue SELECT bietet dir eine Vielzahl von Benefits die auch Auswirkungen auf deinen Code haben. Da Entwickler nicht nach der Anzahl von geschriebenen Zeilen bezahlt werden, können solche Maßnahmen dein Coding übersichtlicher und wartbarer machen.