Data to Code vs. Code to Data
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Beitrag
von SAP_ENTWICKLER (Specialist / 445 / 219 /
6
)
»
Hallo,
im Zusammenhang mit HANA ist immer wieder die Rede von Code Pushdown.
Data to Code verstehe ich noch. Das würde ja eventuell dem entsprechen.
Wobei ich mir da schon den sonst bei mir üblichen SELECT * FROM verkniffen habe und auch das INTO CORRESPONDING nicht (mehr) optimal ist.
Wie soll ich jetzt Code to Data verstehen?
Entspricht die zweite Coding Sequence überhaupt einem Code to Data? Was habe ich jetzt gewonnen wenn alle Sätze z.B. als ALV ausgeben will, die der Selektion entsprachen? Oder macht das ganze erst Sinn wenn ich im zweiten Beispiel im SELECT weitere Logik einbauen müsste, die unter Umständen Summen bildet, oder zusätzliche Datensätze ausschließt etc.? Das würde dann zum Zeitpunkt des Datenbankzugriffs erfolgen.
Gerade die SELECT's des zweiten Beispiels hat man lange vermieden, weil es Releasestände gab, in denen z.B. ein BreakPoint im SELECT zu einem Abbruch geführt hat.
Mein Beitrag / meine Frage soll ja nicht heißen, daß ich die Notwendigkeit einer solchen Umstellung aus Performancegründen nicht einsehe. Die Anpassung ist sicherlich sinnvoll wenn eine solche wesentliche Sache wie Datenbank so dramatisch ändert. Da sollte man die Vorteile in der neuen Architektur auch nutzen.
Nur gibt es in vielen Umgebungen ??????? Eigenentwicklungen der verschiedenen Generationen. Da sollte man sich bevor man riesige Aufwände produziert sicher sein, dass sich der Aufwand in Summe durch eine entsprechende Performace-Optimierung und -Verbesserung auch rechnet.
Habe ich Code to Data richtig verstanden?
Vielen Dank und viele Grüße
Norbert
P.S.: Sollten im Coding grundsätzliche Fehler sein tut es mir leid. Ich habe die wenigen Zeilen direkt in der dieser Seite erfasst.
im Zusammenhang mit HANA ist immer wieder die Rede von Code Pushdown.
Data to Code verstehe ich noch. Das würde ja eventuell dem entsprechen.
Code: Alles auswählen.
TYPES: BEGIN OF gty_output_s.
TYPES: vbeln TYPE vbeln,
kunag TYPE kunnr.
TYPES: END OF gty_output_s.
DATA:
lt_vbak TYPE TABLE OF gty_output_s.
SELECT vbeln kunag FROM vbak INTO CORESSPONDING FIELDS OF TABLE lt_vbak
WHERE vbeln in s_vbeln.
* Weitere Logik auf der internen Tabelle lt_vbak um z.B. die Anzahl der Sätze zu reduzieren etc.
Wie soll ich jetzt Code to Data verstehen?
Code: Alles auswählen.
TYPES: BEGIN OF gty_output_s.
TYPES: vbeln TYPE vbeln,
kunag TYPE kunnr.
TYPES: END OF gty_output_s.
DATA:
lt_vbak TYPE TABLE OF gty_output_s,
ls_vbak TYPE gty_output_s.
SELECT vbeln kunag FROM vbak INTO ls_vbak-vbeln ls_vbak-kunag
WHERE vbeln in s_vbeln.
* Weitere Logik um z.B. die Anzahl der Sätze zu reduzieren etc.
APPEND ls_vbak TO lt_vbak.
ENDSELECT.
Gerade die SELECT's des zweiten Beispiels hat man lange vermieden, weil es Releasestände gab, in denen z.B. ein BreakPoint im SELECT zu einem Abbruch geführt hat.
Mein Beitrag / meine Frage soll ja nicht heißen, daß ich die Notwendigkeit einer solchen Umstellung aus Performancegründen nicht einsehe. Die Anpassung ist sicherlich sinnvoll wenn eine solche wesentliche Sache wie Datenbank so dramatisch ändert. Da sollte man die Vorteile in der neuen Architektur auch nutzen.
Nur gibt es in vielen Umgebungen ??????? Eigenentwicklungen der verschiedenen Generationen. Da sollte man sich bevor man riesige Aufwände produziert sicher sein, dass sich der Aufwand in Summe durch eine entsprechende Performace-Optimierung und -Verbesserung auch rechnet.
Habe ich Code to Data richtig verstanden?
Vielen Dank und viele Grüße
Norbert
P.S.: Sollten im Coding grundsätzliche Fehler sein tut es mir leid. Ich habe die wenigen Zeilen direkt in der dieser Seite erfasst.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Moinsen.
Code to data meint eigentlich, dass ein Teil des Codes dorthin wandert, wo auch die Daten sind: in die Datenbank.
Vorteil dabei ist, dass aufwändige Aufbereitungen, für die das Nachlesen weiterer Daten notwendig sind, direkt dort passieren, wo auch die Daten sind. Dadurch werden zeitraubende Datentransporte (Datenbank -> Applikationsserver) vermieden. Nachteil ist in meinen Augen, dass die Business-Logik nicht mehr durch einen Blick in das ABAP-Programm ersichtlich ist, sondern auch noch andere Stellen begutachtet werden müssen.
Als Schlagworte empfehle ich mal "CDS Views" und "SQLscript", damit wirst Du wohl erstmal fündig.
Grüße,
Haubi
Code to data meint eigentlich, dass ein Teil des Codes dorthin wandert, wo auch die Daten sind: in die Datenbank.
Vorteil dabei ist, dass aufwändige Aufbereitungen, für die das Nachlesen weiterer Daten notwendig sind, direkt dort passieren, wo auch die Daten sind. Dadurch werden zeitraubende Datentransporte (Datenbank -> Applikationsserver) vermieden. Nachteil ist in meinen Augen, dass die Business-Logik nicht mehr durch einen Blick in das ABAP-Programm ersichtlich ist, sondern auch noch andere Stellen begutachtet werden müssen.
Als Schlagworte empfehle ich mal "CDS Views" und "SQLscript", damit wirst Du wohl erstmal fündig.
Grüße,
Haubi
Folgende Benutzer bedankten sich beim Autor Haubi für den Beitrag:
SAP_ENTWICKLER
Beitrag
von SAP_ENTWICKLER (Specialist / 445 / 219 /
6
)
»
Danke für den Hinweis.
Mal abgesehen vom Code Pushdown, welche Variante der zwei Beispiele ist die performantere?
Viele Grüße
Norbert
Mal abgesehen vom Code Pushdown, welche Variante der zwei Beispiele ist die performantere?
Viele Grüße
Norbert
Die erste.
SELECT-ENDSELECT ist so gut wie fast immer die schlechtere Alternative.
SELECT-ENDSELECT ist so gut wie fast immer die schlechtere Alternative.
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
SAP_ENTWICKLER
It depends...ewx hat geschrieben:Die erste.
SELECT-ENDSELECT ist so gut wie fast immer die schlechtere Alternative.
Wenn Du zwischen SELECT und ENDSELECT keine weiteren Datenbankzugriffe hast sollte (!) die Antwortzeit gleich sein. Datenbankseitig wird jeweils ein Array-Fetch stattfinden, über die Ergebnismenge läuft dann der ABAP-Code. Das ist aber sicherlich auch abhängig vom Release-Stand und ggf. der zugrundeliegenden Datenbank.
Ich bevorzuge SELECT...INTO TABLE, weil ich so die Ergebnismenge direkt überblicken kann (z.B. im Debugger).
Folgende Benutzer bedankten sich beim Autor Haubi für den Beitrag:
SAP_ENTWICKLER
Seite 1 von 1
Vergleichbare Themen
17
Antw.
Antw.
5607
Views
Views
2
Antw.
Antw.
2654
Views
Views
2
Antw.
Antw.
2003
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1152
vor 2 Tagen von DeathAndPain 4 / 1152
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1152
vor 2 Tagen von DeathAndPain 4 / 1152