1. Datenbankspezifische Entwicklung
Man sollte sich zunächst darüber bewusst sein, mit welcher Datenbank man arbeitet. Derzeit gibt es noch sehr viele Kunden, bei denen eine relationale Datenbank (Oracle DB, IBM DB2, etc.) eingesetzt ist. Jedoch arbeiten mittlerweile auch einige bereits auf einer Hana DB unter ERP on HANA oder S/4HANA.
Da diese durch ihre In-Memory-Architektur deutlich schnellere Abfrage ermöglicht, lohnt es sich oftmals nicht, Datenbankzugriffe aufzuteilen oder bei Bedarf Daten nachzuladen. Es könnte sogar die Performance deutlich beeinträchtigen, viele Abfrage statt einer sehr großen Komplexen auszuführen.
Darauf sollte man bereits in der Programmarchitektur achten. In der Praxis ist es mir schon ziemlich oft passiert, dass ältere Programmbestandteile nach dem Wechsel auf Hana langsamer wurden. So wurden in einem Programmabschnitt zunächst Daten selektiert und dann im Loop Zusatzdaten von der Datenbank abgefragt. Der Overhead jeder dieser Abfragen plus die total überladene Abfragewarteschlange haben letztendlich zu einem außerordentlichen Performanceproblem im gesamten System geführt.*
Also TL;DR (Too long didn’t read): Auf Hana eher große, komplexe Datenbankabfragen anstatt viele (vorselektierte).
*Wichtig ist zu beachten, dass auch eine Abfrage mit dem Zusatz „FOR ALL ENTRIES IN @DATA“ zwar optimiert ist, aber in der internen Verarbeitung zu einer Masse an Abfragen führt.
2. Datenübergabe durch Methoden
Wenn neue Methoden sauber nach Clean Code Prinzipien entwickelt werden, wird man für die Rückgabe von Daten ausschließlich Returning-Parameter haben, die in ABAP-OO zwangsläufig per VALUE als Datenkopie übergeben werden. Hier sollte jedoch bei der Typisierung überlegt werden, per „TYPE REF TO“ eine Referenz zu übergeben. Somit werden die Daten nicht kopiert sondern nur ein Pointer auf die Daten verwendet.
3. Datenzugriffe auf interne Daten
Um Datenzugriffe zu optimieren, ist es wichtig die Massendaten in einem Tabellentypen mit der für den Anwendungsfall passenden Tabellenart zu halten. Hier gibt es die Auswahl zwischen der Standardtabelle, der sortierten Tabelle und der Hash-Tabelle. Hier ein kleiner Vergleich:
- Standardtabelle: Die Daten werden sequentiell gelesen. Die Lesezeit wächst mit der Tabellengröße.
- Sortierte Tabelle: Die Daten können über den Schlüssel gelesen werden. Der Schlüssel muss nicht eindeutig sein. Die Lesezeit wächst mit der Tabellengröße.
- Hash-Tabelle: Die Daten müssen über den Schlüssel gelesen werden. Der Schlüssel muss eindeutig sein. Die Lesezeit ist konstant.
Aus diesen Informationen ergibt sich, dass performance-optimierte Lesezugriffe ausschließlich mit Hilfe von Schlüsseln möglich ist und die Wahl der Tabellenart auf die Datenstruktur und -menge ankommt.
Falls man doppelte Schlüssel nicht ausschließen kann oder zum Teil Zugriffe ohne Verwendung des Gesamtschlüssels durchführen möchte, sollte man mit der sortierten Tabelle arbeiten. Andernfalls kann eine Hash-Tabelle bei wirklich großen Datenmengen von enormem Vorteil sein, hat jedoch die Einschränkung der obligatorischen eindeutigen Schlüssel. Die Standardtabelle bietet sich nur an, sofern man kleine Datenmengen verarbeitet und keinen Aufwand in die Definition von und den Umgang mit Tabellenschlüsseln investieren möchte.
