Data to Code vs. Code to Data

Alles über die SAPs In-Memory Datenbank HANA
5 Beiträge • Seite 1 von 1
5 Beiträge Seite 1 von 1

Data to Code vs. Code to Data

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.

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. 

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?

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.
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.

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


Re: Data to Code vs. Code to Data

Beitrag von Haubi (Expert / 625 / 20 / 30 ) »
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

Folgende Benutzer bedankten sich beim Autor Haubi für den Beitrag:
SAP_ENTWICKLER

Das ABAP Kochbuch ab sofort bei Amazon...

I'd rather write code that writes code than write code...

Re: Data to Code vs. Code to Data

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

Re: Data to Code vs. Code to Data

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Die erste.
SELECT-ENDSELECT ist so gut wie fast immer die schlechtere Alternative.

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
SAP_ENTWICKLER


Re: Data to Code vs. Code to Data

Beitrag von Haubi (Expert / 625 / 20 / 30 ) »
ewx hat geschrieben:Die erste.
SELECT-ENDSELECT ist so gut wie fast immer die schlechtere Alternative.
It depends...
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

Das ABAP Kochbuch ab sofort bei Amazon...

I'd rather write code that writes code than write code...

Seite 1 von 1

Vergleichbare Themen

17
Antw.
4322
Views
DATA OFFSET und DATA TRANSFER
von Littlered » 21.07.2005 16:01 • Verfasst in ABAP® Core
2
Antw.
2287
Views
DATA BROWSER
von pohlmann-schwarza » 29.08.2008 13:31 • Verfasst in ABAP Objects®
2
Antw.
2364
Views
TYPES und DATA
von bohne » 19.11.2006 23:27 • Verfasst in ABAP® für Anfänger
1
Antw.
2532
Views
Export Data
von Heikeb » 28.08.2012 12:45 • Verfasst in ABAP® für Anfänger
2
Antw.
1607
Views
Create Data
von asano » 11.08.2004 16:54 • Verfasst in ABAP® Core

Über diesen Beitrag


Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

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.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 4 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141