Welchen Tabellentyp soll man nehmen

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
9 Beiträge • Seite 1 von 1
9 Beiträge Seite 1 von 1

Welchen Tabellentyp soll man nehmen

Beitrag von DRABAP (ForumUser / 30 / 0 / 1 ) »
In ABAP gibt es drei versiedene Arten von internen Tabellen. Die richtige Verwendung kann entscheidend für die Performance eines Programmns sein. Im folgenden werden ein paar typische Anwendungsszenarien beschrieben.
Hashtabellen bieten im allgemeinen die beste Performance beim Zugriff. Wenn man sie verwenden kann sollte man es tun. Leider gibt es einige Einschrenkung hinsichtlich ihrer Einsetzbarkeit. Hashtabellen müssen einen eindeutigen Schlüssel besitzen. Es können also keine Duplikate gespeichert werden. Der Zugriff ist nur dann effizient, wenn der volle Schlüssel spezifiziert wird. Die Perfromance ist dann unabhängig von der Größe. Wird nicht der volle Schlüssel verwendet ist die Perfromance linear von der Größe der Tabelle abhändig. Hashtabellen besitzen eine Reihenfolge und können auch sortiert werden.
Sortierte Tabelle können Duplikate speichern. Sie bieten einen effizenten Lesezugriff, der nur sehr in geringem Maße von der Größe der Tabelle abhängt. Dies ist allerdings nur der Fall, wenn der volle Schlüssel oder ein Anfangsstück des Schlüssels angeben wird. Sortierte Tabellen besitzen natürlich eine feste Reihenfolge. Sie können allerdings nur gemäß ihres Schlüssels sortiert werden 8was allerdings nicht nötig ist, da seei ohnehin sortiert sind).
Standardtabelle bieten nur einen ineffizenten Lesezugriff (die gesamte Tabelle wird sequentiell durchsucht). Es gibt allerdings einige Dinge, die nur mit Standardtabellen funktionieren wie z.B. der RFC. Will man beim lesen eine bessere Effiziens erreichen, so muß man die Tabelle sortieren und dann den READ ... BINARY SERACH verwenden. Hierbei sind jedoch einige Fallstricke zu beachten. Trotzdem ist zu sagen: wenn man oft mit verschiedenen Schlüsseln suchen will, bieten sich Standardtabellen an. Man kann die Tabelle dann jeweils einmal gemäß des Schlüssels sortieren und dann die effiziente Binärsuche verwenden. Standardtabellen sind also sehr flexibel.
Dr. ABAP

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Beitrag von hsv (ForumUser / 24 / 0 / 0 ) »
das ist ja alles schön und gut, aber was spricht denn gegen eine standard tabelle, die ich sortiere und dann mit binary search auf diese zugreife?
gut, es mag zwar verbohrt klingen, aber warum sollte ich eine hash oder sorted table verwenden, wenn ich eine ähnliche performence mit einer standardtabelle erreichen kann?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
@DrAbap:
Da ich bisher noch nie mit HashTables gearbeitet führen mich Ihre Ausführungen zu folgendem Schluss:
Wenn ich ein COLLECT in eine Hashtabelle mache müsste dies doch einen enormen Geschwindigkeitszuwachs geben verglichen mit einem COLLECT in eine Standardtabelle, oder?

@hsv:
Sehe ich ähnlich - außer dass man sich den Zusatz "Binary Search" spart.

Aber die Sorted-Tables haben zumindest für mich 2 Vorteile:

1.) Wenn sie -warum auch immer - nicht sortiert sind teilt mir das System dies automatisch mit. ( :D mit einem Kurzdump :D )
2.) Wenn ich geschachtelte LOOPs habe ist es SEHR viel performanter wenn die innere Schleife via "WHERE"-Bedingung durchlaufen wird und diese einen Teilschlüssel der durchlaufenen Tabelle darstellt.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Beitrag von hsv (ForumUser / 24 / 0 / 0 ) »
das mit der where bedingung bei einer loop anweisung geht auch mit der standard tabelle, man muß nur diese vorher sortieren.

der andere trick ist, daß man sowieso keine geschachtelten loop anweisungen verwendet. ;-)

Beitrag von Gast ( / / 0 / 3 ) »
black_adept hat geschrieben:@DrAbap:
Da ich bisher noch nie mit HashTables gearbeitet führen mich Ihre Ausführungen zu folgendem Schluss:
Wenn ich ein COLLECT in eine Hashtabelle mache müsste dies doch einen enormen Geschwindigkeitszuwachs geben verglichen mit einem COLLECT in eine Standardtabelle, oder?
Da hast Du wohl schon länger nicht mehr in die F1-Hilfe zu COLLECT geschaut.
In alten Releases (bis 2.x) war COLLECT wirklich langsam, es war schneller, eine verdichtete itab mit READ ... BINARY SEARCH und MODIFY oder INSERT (je nach SY-SUBRC) mit INDEX SY-TABIX aufzubauen.
Jetzt wird, wenn die Ziel-Tabelle leer ist, temporär eine Hash-Verwaltung für die Tabelle mitgeführt. So dass die Performance mit COLLECT auf Hashtabellen vergleichbar ist.
Voraussetzung: es werden nicht mit MODIFY "Key"-Felder verändert oder mit INSERT ... INDEX bzw. APPEND Einträge hinzugefügt.
Auch eim SORT sollte - wenn überhaupt - erst nach vollständigem Füllen der itab per COLLECT erfolgen.

Sowohl in OSS-Hinweisen als auch in der Doku ist beschrieben, wie man zur Laufzeit ermitteln kann, ob eine temporär für die Tabelle angelegte Hash-Verwaltung existiert oder nicht.

(Ob ein REFRESH ausreicht oder ob ein FREE nötig ist, wenn die nicht als Hashtabelle definierte Tabelle schon gefüllt ist und anschließend mit COLLECT gefüllt werden soll, weiß ich nicht. In der Doku habe ich nichts gefunden, ausprobieren wollte ich es nicht - zumal man sich auf nicht dokumentiertes Verhalten nicht unbedingt verlassen sollte. Also nehme ich im Zweifelsfall ein FREE ...)

Und: man kann nicht mehr als 2^22 Einträge in eine Hash-Tabelle aufnehmen (egal ob type hashed table oder standard table mit COLLECT aufgebaut). Ist m.E. auch nirgends beschrieben. Aber so viele Einträge in einer Hashtabelle dürfte man selten benötigen.
@hsv:
Sehe ich ähnlich - außer dass man sich den Zusatz "Binary Search" spart.

Aber die Sorted-Tables haben zumindest für mich 2 Vorteile:

1.) Wenn sie -warum auch immer - nicht sortiert sind teilt mir das System dies automatisch mit. ( :D mit einem Kurzdump :D )
2.) Wenn ich geschachtelte LOOPs habe ist es SEHR viel performanter wenn die innere Schleife via "WHERE"-Bedingung durchlaufen wird und diese einen Teilschlüssel der durchlaufenen Tabelle darstellt.
Der Zugriff bei READ ... WITH KEY hängt (s. F1-Hilfe zu READ) bei nicht sortierten Tabellen linear, bei Sortierten tabellen logarithmisch, bei hashtabellen gar nicht von der Anzahl Tabellenzeilen ab.
Insofern gibt es schon je nach Anwendung Optimierungsmöglichkeiten.

Und für geschachtelte LOOPs hält die SE30 unter Tipps&Tricks auch ein performantes Beispiel bei standard tables bereit:
nicht so

Code: Alles auswählen.

* Entries: 100 (ITAB1), 1000 (ITAB2)
* Line width: 100
* Both tables sorted by key K

LOOP AT ITAB1 INTO WA1.
  LOOP AT ITAB2 INTO WA2
                WHERE K = WA1-K.
    " ...
  ENDLOOP.
ENDLOOP.
sondern so:

Code: Alles auswählen.

* Entries: 100 (ITAB1), 1000 (ITAB2)
* Line width: 100
* Both tables sorted by key K

I = 1.
LOOP AT ITAB1 INTO WA1.
  LOOP AT ITAB2 INTO WA2 FROM I.
    IF WA2-K <> WA1-K.
      I = SY-TABIX.
      EXIT.
    ENDIF.
    " ...
  ENDLOOP.
ENDLOOP.

Probiert es doch mal aus

Beitrag von Olaf P. ( / / 0 / 3 ) »
Moin zusammen,
wer einfach stumpf weiter nur Tabellen vom Typ STANDARD verwendet, verschenkt viel Performance. Bei Direktzugriffen ist der Zugriff auf eine Hashed-Table erheblich schneller, als auf eine Standard (oder Sorted) Table.

Leider habe ich schon viele Entwickler getroffen, die immer noch Tabellen mit itab type xyz occurs 0 (und vielleicht noch mit HEADER LINE) definieren, weil es so schön bequem ist. Wenn die Programme dann langsam sind, ist das System schuld, dabei sind die Programme einfach Schrott.

Probiert es doch einfach mal aus, schaut Euch die Zeiten für die Zugriffe an. Dann werdet Ihr sehen, was Ihr bisher verschenkt habt.

VG Olaf

Re: Welchen Tabellentyp soll man nehmen

Beitrag von Gast ( / / 0 / 3 ) »
DRABAP hat geschrieben:In ABAP gibt es drei versiedene Arten von internen Tabellen. Die richtige Verwendung kann entscheidend für die Performance eines Programmns sein. Im folgenden werden ein paar typische Anwendungsszenarien beschrieben.
Hashtabellen bieten im allgemeinen die beste Performance beim Zugriff. Wenn man sie verwenden kann sollte man es tun. Leider gibt es einige Einschrenkung hinsichtlich ihrer Einsetzbarkeit. Hashtabellen müssen einen eindeutigen Schlüssel besitzen. Es können also keine Duplikate gespeichert werden. Der Zugriff ist nur dann effizient, wenn der volle Schlüssel spezifiziert wird. Die Perfromance ist dann unabhängig von der Größe. Wird nicht der volle Schlüssel verwendet ist die Perfromance linear von der Größe der Tabelle abhändig. Hashtabellen besitzen eine Reihenfolge und können auch sortiert werden.
Sortierte Tabelle können Duplikate speichern. Sie bieten einen effizenten Lesezugriff, der nur sehr in geringem Maße von der Größe der Tabelle abhängt. Dies ist allerdings nur der Fall, wenn der volle Schlüssel oder ein Anfangsstück des Schlüssels angeben wird. Sortierte Tabellen besitzen natürlich eine feste Reihenfolge. Sie können allerdings nur gemäß ihres Schlüssels sortiert werden, was allerdings nicht nötig ist, da seei ohnehin sortiert sind).
Standardtabelle bieten nur einen ineffizenten Lesezugriff (die gesamte Tabelle wird sequentiell durchsucht). Es gibt allerdings einige Dinge, die nur mit Standardtabellen funktionieren wie z.B. der RFC (in älteren Releases). Will man beim lesen eine bessere Effiziens erreichen, so muß man die Tabelle sortieren und dann den READ ... BINARY SERACH verwenden. Hierbei sind jedoch einige Fallstricke zu beachten. Trotzdem ist zu sagen: wenn man oft mit verschiedenen Schlüsseln suchen will, bieten sich Standardtabellen an. Man kann die Tabelle dann jeweils einmal gemäß des Schlüssels sortieren und dann die effiziente Binärsuche verwenden. Standardtabellen sind also sehr flexibel.

Beitrag von meinrad (ForumUser / 67 / 0 / 0 ) »
Hallo,
Da ich meine wesentlichen Programmiererfahrung bezüglich Performance mit der Uralt-Sprache COBOL gemacht habe und meine ersten ABAP-Erfahrungen mit der Release 3.1, arbeite ich sehr gerne mit LOOP und habe kaum Perfomance Probleme. Ich benutze eine nahezu Programmiersprachen unabhängige Misch- und Gruppenwechsel-Logik.
Wenn ich zwei große Tabellen habe, aus den ich Daten mischen muss, so sortiere ich sie über gemeinsame Schlüsselfelder. Die Tabelle, die mehr Einträge hat bzw. die mehr unterschiedliche Einträge bezüglich der Ordnungsbegriffe hat, ist die führende Tabelle. Bei Wechsel des Ordnungsbegriffs (Gruppenwechsel oft mit selbst definierter Struktur NEU/ALT) lese ich die zweite Tabelle OHNE WHERE-Bedingung aber mit FROM INDEX (Beim 1. Zugriff = 1) . Den inneren LOOP breche ich ab, wenn der Ordnungsbegriff größer ist und ich merke mir den Index zum Abbruch-Zeitpunkt um ihn beim nächsten LOOP zu verwenden.
Somit lese ich also zwei Tabellen: Eine mit Bewegungsdaten und eine andere mit Stammdaten je nur einmal durch. Da ich den Inhalt der letzten Zeile der im inneren LOOP durchlaufenen Tabelle kenne, führe ich den inneren LOOP erst wieder aus, wenn die Schlüssel des äußeren LOOPS >= sind. Beachten muss ich die Verarbeitung des ersten und des letzten Satzes.

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Anonymous hat geschrieben: Der Zugriff bei READ ... WITH KEY hängt (s. F1-Hilfe zu READ) bei nicht sortierten Tabellen linear, bei Sortierten tabellen logarithmisch, bei hashtabellen gar nicht von der Anzahl Tabellenzeilen ab.
Insofern gibt es schon je nach Anwendung Optimierungsmöglichkeiten.
Damit ergeben sich doch folgende Formeln für eine Tabelle mit N Zeilen:
N = Anzahl Tabellenzeilen, T1,T2,T3 = Zugriffszeit, C1,C2,C3 sind Konstanten:

1.) nicht sortierte Tabelle:
T1 = C1 * N

2.) sortierte Tabelle:
T2 = C2 * LOG(N) { LOG = Natürlicher Log. }

3.) Hashtable:
T3 = C3


Gibt es eigentlich irgendwelche Aussagen über die Größenordnungen von C1, C2 und C3? Bei Limesbildung für N gegen unendlich sieht man schon dass Hashtabellen besser sind als Sortierte als unsortierte. Aber wie sieht das denn bei nicht so großen N aus. Bzw. bis zu welchen N ist die Hashtabelle tatsächlich besser als die sortierte?
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Seite 1 von 1

Vergleichbare Themen

2
Antw.
1457
Views
Was kann man statt fin nehmen ?
von bohne » 20.12.2006 10:49 • Verfasst in ABAP® Core
3
Antw.
1917
Views
Verständnisfrage: Excel zu SAP (Was als Client nehmen?)
von Benjamin654 » 02.02.2009 22:42 • Verfasst in ABAP® für Anfänger
22
Antw.
19725
Views
CUS&_Varianten von anderen ändern? Schutz nehmen?
von Kali » 26.10.2012 14:12 • Verfasst in Basis
4
Antw.
2462
Views
Tabellentyp
von JohnLocklay » 06.07.2017 14:10 • Verfasst in ABAP® Core
16
Antw.
2351
Views
Sortierter Tabellentyp für Objekttabelle
von ralf.wenzel » 11.09.2019 12:15 • Verfasst in ABAP Objects®

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.