ABAP - Der richtige Schlüssel
Wie sieht es eigentlich bei der Nutzung von internen Tabellen aus? Immer noch TYPE TABLE in ABAP und die Tabelle ist fertig definiert?
Inhaltsverzeichnis
In diesem Artikel schauen wir uns einmal die Tabellen an, wie du ordentliche Schlüssel für deine Tabelle definierst und was du bei der Performance berücksichtigen solltest.
Einleitung
Immer wieder stolpern wir bei Code Reviews oder im SAP Standard über die gleichen Tabellendefinitionen. Meist wird dort "lieblos" eine Tabelle mit TYPE TABLE und dann irgendeine Struktur oder Tabelle definiert. Grundsätzlich kann ein Entwickler damit arbeiten und wenn wir im Bereich eines Reports sind, auch weitere Typen damit definieren. Wechseln wir allerdings den Kontext Richtung OO und wollen Methoden mit RETURNING Parameter definieren, dann erhalten wir bereits die erste Fehlermeldung, dass der Typ nicht vollständig definiert ist. Viele Entwickler fragen sich dann wahrscheinlich, habe ich nun etwas falsch gemacht?
Arten
Grundsätzlich gibt es im Moment drei Arten von Tabellen: Standard, Sorted und Hashed. In den meisten Fällen wurde damals eigentlich die Standard Tabelle verwendet und sich keine großen Gedanken gemacht, wie es mit der Performance aussieht. Sorted und Hashed Tabellen benötigten immer einen Schlüssel, sind damit also erst einmal etwas schwieriger zu definieren. Du solltest dir auch zu Beginn der Entwicklung Gedanken machen, ob du einen eindeutigen Schlüssel in der Tabelle hast oder ob dir später doppelte Schlüssel Probleme machen können. Dazu einige verschiedene Tabellendefinitionen:
DATA standard_table TYPE STANDARD TABLE OF exmaple_structure.
DATA sorted_table TYPE SORTED TABLE OF exmaple_structure WITH NON-UNIQUE KEY key_field.
DATA hashed_table TYPE HASHED TABLE OF exmaple_structure WITH UNIQUE KEY key_field.
Die Standardtabelle hat keinen Schlüssel, damit können doppelte und leere Datensätze eingefügt werden. Die Datensätze in der Tabelle sind allerdings nicht sortiert und werden nacheinander in die Tabelle eingefügt. Die sortierte Tabelle hat einen Non-Unique Schlüssel, damit kann der gleiche Schlüssel mehrfach eingefügt werden, allerdings werden die Datensätze nach dem Schlüssel in der Tabelle eingefügt und sortiert. Die gehashte Tabelle benötigt immer einen eindeutigen Schlüssel und es gelten die gleichen Regeln wie bei der sortierten Tabelle.
Schlüssel
Bereits im Beispiel oben haben wir Schlüssel definiert, da diese für sortierte und gehashte Tabellen Pflicht sind. Wie sieht es daher mit Standardtabellen aus? Hier gibt es aktuell zwei Arten von Schlüsseln, die wie folgt definiert werden:
DATA table_default TYPE STANDARD TABLE OF exmaple_structure WITH DEFAULT KEY.
DATA table_empty TYPE STANDARD TABLE OF exmaple_structure WITH EMPTY KEY.
Der EMPTY Key ist die eigentliche Empfehlung von SAP, dann hat die Tabelle keinen Schlüssel und es erfolgt auch keine Verwaltung eines möglichen Schlüssels. Hingegen ist der DEFAULT Key der sogenannte Schrittschlüssel. Dabei werden alle zeichenartigen Felder genommen und daraus der Schlüssel erzeugt. Je nach Struktur kann der Schlüssel dann sehr viele Felder enthalten, was wiederum Performance bei der Verwaltung kostet, obwohl du dann vielleicht nicht einmal den Schlüssel nutzt.
Weitere Informationen zum Standard bzw. Default Key findest du in der Dokumentation unten. Dort wird auch noch einmal genau beschrieben, wie sich der Schlüssel zusammensetzt.
TYPE TABLE
Definierst du eine Tabelle einfach nur als TYPE TABLE, dann solltest du im ersten Schritt fragen, ob der Entwickler es nicht besser weiß, faul ist oder kein Interesse am Inhalt der Tabelle oder der Menge an Daten hat. Hierbei handelt es sich nicht mehr um Best Practice.
DATA table TYPE TABLE OF exmaple_structure.
Im Grunde hast du nun folgendes definiert:
- Standard Tabelle
- Default Key
Daher wäre es besser auch gleich für neue Entwickler den eigentlichen Typen anzugeben. Daher würden wir hier die Art der Tabelle definieren und angeben, dass uns der Schlüssel egal ist und wir keinen benötigen:
DATA table_correct TYPE STANDARD TABLE OF exmaple_structure WITH EMPTY KEY.
Arbeit mit Tabellen
Zur Arbeit mit Tabellen hatten wir bereits in der Vergangenheit eine kleine Serie gemacht, Dabei gehen wir vor allem auf die neue Methode mit [] ein. Zusätzlich schauen wir uns auch die Performance von verschiedenen Tabellentypen an, damit du eine Vorstellung vom richtigen Typen bekommst.
Verwendest du eigentlich noch APPEND oder schon für alles INSERT? In diesem Artikel schauen wir uns die Unterschiede an und geben eine Empfehlung, was du eigentlich nutzen solltest. Grundsätzlich würden wir dir empfehlen, dir lieber einmal mehr Gedanken über den Typen zu machen, bevor du später in Probleme läufst, dabei können die folgenden Fragen helfen:
- Wie viele Datensätze erwarte ich in der Verarbeitung in dieser Tabelle?
- Verarbeite ich die Datensätze in einer Schleife oder habe ich Lesezugriffe per READ oder []?
- Gibt es einen Schlüssel in den Daten? Ist dieser eindeutig?
- Muss ich die Daten öfters auch Schreiben oder neue Datensätze einfügen?
Vollständiges Beispiel
Damit du das Beispiel nachvollziehen kannst, findest du hier noch einmal den kompletten Quellcode der ausführbaren Klasse. Damit kannst du die Klasse ins System laden und selbst das Verhalten nachstellen.
CLASS zcl_bs_demo_table_keys DEFINITION
PUBLIC FINAL
CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES if_oo_adt_classrun.
PRIVATE SECTION.
TYPES:
BEGIN OF exmaple_structure,
key_field TYPE c LENGTH 20,
description TYPE string,
number TYPE i,
date TYPE d,
time TYPE t,
END OF exmaple_structure.
METHODS types_of_tables
IMPORTING !out TYPE REF TO if_oo_adt_classrun_out.
METHODS type_table
IMPORTING !out TYPE REF TO if_oo_adt_classrun_out.
METHODS keys
IMPORTING !out TYPE REF TO if_oo_adt_classrun_out.
ENDCLASS.
CLASS zcl_bs_demo_table_keys IMPLEMENTATION.
METHOD if_oo_adt_classrun~main.
types_of_tables( out ).
keys( out ).
type_table( out ).
ENDMETHOD.
METHOD types_of_tables.
DATA standard_table TYPE STANDARD TABLE OF exmaple_structure.
DATA sorted_table TYPE SORTED TABLE OF exmaple_structure WITH NON-UNIQUE KEY key_field.
DATA hashed_table TYPE HASHED TABLE OF exmaple_structure WITH UNIQUE KEY key_field.
out->write( standard_table ).
out->write( sorted_table ).
out->write( hashed_table ).
ENDMETHOD.
METHOD keys.
DATA table_default TYPE STANDARD TABLE OF exmaple_structure WITH DEFAULT KEY.
DATA table_empty TYPE STANDARD TABLE OF exmaple_structure WITH EMPTY KEY.
out->write( table_default ).
out->write( table_empty ).
ENDMETHOD.
METHOD type_table.
DATA table TYPE TABLE OF exmaple_structure.
DATA table_correct TYPE STANDARD TABLE OF exmaple_structure WITH EMPTY KEY.
out->write( table ).
out->write( table_correct ).
ENDMETHOD.
ENDCLASS.
Fazit
In diesem Artikel hatten wir uns die verschiedenen Typen und Grundlagen von internen Tabellen angeschaut. Grundsätzlich ist die richtige Art von Tabelle für deine Entwicklung entscheidend und du solltest dir am Anfang einmal mehr Gedanken machen, wie du die Tabelle anlegen willst. Aber bitte nicht mehr mit TYPE TABLE.
Weitere Informationen:
SAP Help - Standard Key
