SELECT ... INTO TABLE @DATA... als Quelle für Tabellenausdrücke
15 Beiträge
•
Seite 1 von 1
15 Beiträge
Seite 1 von 1
Hallo,
die neueren Sprachfeatures wie "SELECT ... INTO TABLE @DATA(..." und Zugriff über Tabellenausdrücke sind im Alltag ja echt hilfreich.
Was mich an der Kombination aber richtig stört, ist die fehlende Möglichkeit weder bei "...INTO TABLE @DATA(..." einen Index zu definieren noch beim Tabellenausdruck ein "BINARY READ" mitzugeben.
Somit sieht ein
zwar wesentlich eleganter aus als ein oldschool
aber ist um Größenordnungen langsamer, da kein Index-Zugriff erfolgt.
Wie macht ihr das?
* Auf die Bequemlichkeit von "...INTO TABLE @DATA(" verzichten (und vorher eine sorted oder hashed Table definieren)
* oder auf die Eleganz von Tabellenausdrücken verzichten (zumindest im Loop) und mit READ TABLE auf die Daten zugreifen?
oder gibt es womöglich doch eine bessere Möglichkeit?
die neueren Sprachfeatures wie "SELECT ... INTO TABLE @DATA(..." und Zugriff über Tabellenausdrücke sind im Alltag ja echt hilfreich.
Was mich an der Kombination aber richtig stört, ist die fehlende Möglichkeit weder bei "...INTO TABLE @DATA(..." einen Index zu definieren noch beim Tabellenausdruck ein "BINARY READ" mitzugeben.
Somit sieht ein
Code: Alles auswählen.
<current_line>-value = VALUE #( mytab[ id = <current_line>-id DEFAULT 0 ]-value ).Code: Alles auswählen.
READ TABLE mytab ASSIGNING FIELD-SYMBOL(<lookup_line>) WITH KEY id = <current_line>-id BINARY SEARCH.
IF sy-subrc = 0.
<current_line>-value = <loopup_line>-value.
ENDIF.
Wie macht ihr das?
* Auf die Bequemlichkeit von "...INTO TABLE @DATA(" verzichten (und vorher eine sorted oder hashed Table definieren)
* oder auf die Eleganz von Tabellenausdrücken verzichten (zumindest im Loop) und mit READ TABLE auf die Daten zugreifen?
oder gibt es womöglich doch eine bessere Möglichkeit?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4287 / 214 /
1142
)
»
Sowohl als auch:
Ich verwende meistens eigene Tabelletypen/Strukturen für die Datenabfrage und jetzt auch immer öfter basierend auf (CDS-)Views um die Datenmenge (HANA) bzw. die Schreibarbeit/Komplexität bei großen Joins zu reduzieren und Wiederverwendbarkeit zu gewährleisten.
Wenns schnell gehen soll ein SELECT mit ORDER BY und dann ein READ TABLE mit BINARY SEARCH.
Ich verwende meistens eigene Tabelletypen/Strukturen für die Datenabfrage und jetzt auch immer öfter basierend auf (CDS-)Views um die Datenmenge (HANA) bzw. die Schreibarbeit/Komplexität bei großen Joins zu reduzieren und Wiederverwendbarkeit zu gewährleisten.
Wenns schnell gehen soll ein SELECT mit ORDER BY und dann ein READ TABLE mit BINARY SEARCH.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 3950 / 105 /
886
)
»
Moin,
das ist in der Tat eines der Mankos der Inlinedeklaration.
Da ich die Lookup-Tabelle meist in einer anderen Methode lese und puffere als dort, wo ich das einsetze, komme ich in diesen Fällen nicht umhin, das selbst explizit zu definieren. Aber wenn das tatsächlich nur lokal benötigt wird, verwende ich inzwischen meist auch explizit definierte Typen. Wenn die Anzahl der Felder gering ist oder ich mir relativ sicher bin, dass ich an der Typdefinition später wohl kaum noch rumschrauben werde, definiere ich den Typ vorab explizit selbst, wenn das noch sehr im Flux ist oder die Anzahl der Felder zu groß (und ich zu faul ), dann folgendes Konstrukt.
Danach arbeite ich mit lt_data2 statt lt_data. Und das ist einer der Fälle, wo LIKE beweist, dass es weiterhin eine Daseinsberechtigung hat.
das ist in der Tat eines der Mankos der Inlinedeklaration.
Da ich die Lookup-Tabelle meist in einer anderen Methode lese und puffere als dort, wo ich das einsetze, komme ich in diesen Fällen nicht umhin, das selbst explizit zu definieren. Aber wenn das tatsächlich nur lokal benötigt wird, verwende ich inzwischen meist auch explizit definierte Typen. Wenn die Anzahl der Felder gering ist oder ich mir relativ sicher bin, dass ich an der Typdefinition später wohl kaum noch rumschrauben werde, definiere ich den Typ vorab explizit selbst, wenn das noch sehr im Flux ist oder die Anzahl der Felder zu groß (und ich zu faul ), dann folgendes Konstrukt.
Code: Alles auswählen.
SELECT viele_felder
FROM dbtab
INTO TABLE @DATA(lt_data).
TYPES: lts_data LIKE LINE OF lt_data,
ltt_data TYPE HASHED TABLE OF lts_data WITH UNIQUE KEY keyfield(s).
DATA(lt_data2) = CORRESPONDING ltt_data( lt_data ).
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
a-dead-trousers • whaslbeck
Beitrag
von a-dead-trousers (Top Expert / 4287 / 214 /
1142
)
»
Kein schlechter Ansatz.
Trotzdem sollte für Anfänger noch dazu gesagt werden, dass bei großen Datenmengen Vorsicht geboten ist, weil es höchstwahrscheinlich zu einer Verdopplung der Daten kommt. ABAP bietet zwar diverse Tricks unter der Haube an um Kopieroperationen zu "optimieren" aber gerade bei einer allfällig anderen Sortierung als in der Ursprungstabelle dürfte die Kopie zwangsläufig sofort erzeugt werden.
Trotzdem sollte für Anfänger noch dazu gesagt werden, dass bei großen Datenmengen Vorsicht geboten ist, weil es höchstwahrscheinlich zu einer Verdopplung der Daten kommt. ABAP bietet zwar diverse Tricks unter der Haube an um Kopieroperationen zu "optimieren" aber gerade bei einer allfällig anderen Sortierung als in der Ursprungstabelle dürfte die Kopie zwangsläufig sofort erzeugt werden.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
whaslbeck
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1806 / 214 /
396
)
»
Ich habe nicht verstanden, was das eine mit dem anderen zu tun hat, denn Dein Beispiel enthält doch überhaupt keinen SELECT ... INTO TABLE @DATA.whaslbeck hat geschrieben: ↑22.05.2023 09:54die neueren Sprachfeatures wie "SELECT ... INTO TABLE @DATA(..." und Zugriff über Tabellenausdrücke sind im Alltag ja echt hilfreich.
Was mich an der Kombination aber richtig stört, ist die fehlende Möglichkeit weder bei "...INTO TABLE @DATA(..." einen Index zu definieren noch beim Tabellenausdruck ein "BINARY READ" mitzugeben.
Somit sieht einzwar wesentlich eleganter ausCode: Alles auswählen.
<current_line>-value = VALUE #( mytab[ id = <current_line>-id DEFAULT 0 ]-value ).
Das finde ich aber richtig eklig, denn dann hast Du ja einen TYPES-Befehl inmitten der Routine anstatt am Anfang. Sowas wäre bei mir bestenfalls als temporäre Krücke denkbar, aber niemals in einem finalen Code.black_adept hat geschrieben: ↑22.05.2023 13:41wenn das noch sehr im Flux ist oder die Anzahl der Felder zu groß (und ich zu faul ), dann folgendes Konstrukt.Code: Alles auswählen.
SELECT viele_felder FROM dbtab INTO TABLE @DATA(lt_data). TYPES: lts_data LIKE LINE OF lt_data, ltt_data TYPE HASHED TABLE OF lts_data WITH UNIQUE KEY keyfield(s). DATA(lt_data2) = CORRESPONDING ltt_data( lt_data ).
Im übrigen verstehe ich auch den Nutzen nicht, denn wenn Du viele_felder ohnehin im Code aufzählst, dann kannst Du es auch gleich in einem TYPE-Block am Anfang der Routine tun und dann mit einem ordentlichen SELECT * INTO CORRESPONDING FIELDS OF TABLE arbeiten und hast einen sauberen und performanten Code.
Dem kann (und IMHO sollte) man leicht begegnen, indem man gleich nach dem Umkopieren einen FREE auf die temporäre Hilfstabelle (hier: lt_data) ausführt.a-dead-trousers hat geschrieben: ↑22.05.2023 14:29Trotzdem sollte für Anfänger noch dazu gesagt werden, dass bei großen Datenmengen Vorsicht geboten ist, weil es höchstwahrscheinlich zu einer Verdopplung der Daten kommt.
Den hab ich nicht explizit dazugeschrieben, aber natürlich war das so gemeint, dass die interne Tabelle "mytab" durch ein SELECT ... INTO TABLE @DATA(mytab) erstellt wird.DeathAndPain hat geschrieben: ↑15.06.2023 19:59Ich habe nicht verstanden, was das eine mit dem anderen zu tun hat, denn Dein Beispiel enthält doch überhaupt keinen SELECT ... INTO TABLE @DATA.
Aber ein SELECT * INTO CORRESPONDING... holt doch erst die Daten ALLER DB-Felder aus der DB in den Appserver und matched diese dort dann in die passenden Felder der Zieltabelle. Gefällt mir auch nicht so, man will ja eigentlich den Datentransfer DB=>Appserver minimieren.DeathAndPain hat geschrieben: ↑15.06.2023 19:59Im übrigen verstehe ich auch den Nutzen nicht, denn wenn Du viele_felder ohnehin im Code aufzählst, dann kannst Du es auch gleich in einem TYPE-Block am Anfang der Routine tun und dann mit einem ordentlichen SELECT * INTO CORRESPONDING FIELDS OF TABLE arbeiten und hast einen sauberen und performanten Code.
Oder ist die OpenSQL Runtime so schlau und baut aus einem SELECT * ein SQL mit SELECT feld1, feld2 etc. mit allen Feldern, die sowohl in der Struktur der Quell-DB-Tabelle als auch in der Struktur der Ziel-Int.Tab vorhanden sind? (wär ja durch einen Ableich der DDICT Strukturen möglich). Ich denke aber eher nicht.?!?
Beitrag
von DeathAndPain (Top Expert / 1806 / 214 /
396
)
»
Ich könnte mir durchaus vorstellen, dass ABAP da gewisse Optimierungen eingebaut hat. Aber selbst wenn das nicht so sein sollte: Also als ich im Jahre 2001 mit ABAP angefangen habe, da hat es noch richtig wahrnehmbar einen Unterschied gemacht, wie viele Spalten man aus einer Tabelle gelesen hat und wie viele Daten dementsprechend zu bewegen waren.
In den letzten Jahren ist das aber unter die Wahrnehmungsschwelle gerutscht. Ein sauberer, gut les- und wartbarer Code ist wesentlich wertvoller. Für viel wichtiger halte ich, alle benötigten Daten einer Datenbanktabelle mit FOR ALL ENTRIES IN in einem Rutsch in eine indizierte interne Puffertabelle zu lesen und dann die benötigten Einzeldaten von dort zu entnehmen, anstatt für jede Materialnr/Auftragsnr/Personalnr/whatever einen SELECT SINGLE zu machen. Das spart richtig Rechenzeit!
Wenn Du bei Deinem einen SELECT dann einen * mit INTO CORRESPONDING FIELDS OF TABLE machst, dann kannste die Mehrzeit unter Ulk verbuchen.
In den letzten Jahren ist das aber unter die Wahrnehmungsschwelle gerutscht. Ein sauberer, gut les- und wartbarer Code ist wesentlich wertvoller. Für viel wichtiger halte ich, alle benötigten Daten einer Datenbanktabelle mit FOR ALL ENTRIES IN in einem Rutsch in eine indizierte interne Puffertabelle zu lesen und dann die benötigten Einzeldaten von dort zu entnehmen, anstatt für jede Materialnr/Auftragsnr/Personalnr/whatever einen SELECT SINGLE zu machen. Das spart richtig Rechenzeit!
Wenn Du bei Deinem einen SELECT dann einen * mit INTO CORRESPONDING FIELDS OF TABLE machst, dann kannste die Mehrzeit unter Ulk verbuchen.
Beitrag
von a-dead-trousers (Top Expert / 4287 / 214 /
1142
)
»
Und wenn man es schafft den FOR ALL ENTRIES IN wegzulassen und stattdessen z.B. RANGE Tabellen oder ähnliches zu verwenden, wird das ganze noch schneller.
Übrigens unter Hana sollte man doch darauf achten nicht zu viele unnötige Felder auszulesen. Ich behelfe mir da meistens mit Views (DB, CDS, ...) um das Programmcoding selbst kurz zu halten und nicht allzu große (und komplizierte) SELECT-Statements zu haben. Stichwort Code Pushdown.
Übrigens unter Hana sollte man doch darauf achten nicht zu viele unnötige Felder auszulesen. Ich behelfe mir da meistens mit Views (DB, CDS, ...) um das Programmcoding selbst kurz zu halten und nicht allzu große (und komplizierte) SELECT-Statements zu haben. Stichwort Code Pushdown.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1806 / 214 /
396
)
»
FOR ALL ENTRIES IN wird SAP-seitig mit speziell auf die jeweilige Datenbank angepassten Parametern umgesetzt. Meines Wissens wird es in den IN-Operator von SQL gewandelt in datenbankspezifisch großen Häppchen. Ich habe damit eine exzellente Performance, mit der ich die Leistung der Programmierer anderer Codes (SAP eingeschlossen) in aller Regel deutlich schlage. (Voraussetzung sind korrekt auf die verwendete Datenbank eingestellte Systemparameter. Da gibt es Hinweise dazu, auch wenn ich die Nummern nicht mehr im Kopf habe. Aber für die wesentlichen Datenbanken stehen die Systemparameter nach meiner Erinnerung schon im Auslieferungszustand richtig.)
Wenn man eine RANGE-Tabelle machen würde, dann würde das nicht nur den Code aufblähen, sondern man hätte darin eine Anzahl von I-EQ-Zeilen mit der Nummer. Damit kann SAP auch nichts anderes machen, als es in den IN-Operator von SQL zu wandeln. Von daher habe ich erhebliche Zweifel, ob da tatsächlich eine bessere Performance bei herauskäme. Das scheint mir noch nicht einmal theoretisch möglich zu sein.
Wenn man eine RANGE-Tabelle machen würde, dann würde das nicht nur den Code aufblähen, sondern man hätte darin eine Anzahl von I-EQ-Zeilen mit der Nummer. Damit kann SAP auch nichts anderes machen, als es in den IN-Operator von SQL zu wandeln. Von daher habe ich erhebliche Zweifel, ob da tatsächlich eine bessere Performance bei herauskäme. Das scheint mir noch nicht einmal theoretisch möglich zu sein.
Beitrag
von a-dead-trousers (Top Expert / 4287 / 214 /
1142
)
»
FOR ALL ENTRIES IN wird vor allem wenn mehrere Felder gleichzeitig abgefragt werden, blockweise abgearbeitet. Das geht auch nicht anders, weil sich das logisch nicht in mehrere IN Anweisungen auftrennen lässt. Wenn nur ein Feld abgefragt wird, lässt sich das vielleicht in einen RANGE umwandeln aber auch nur dann.
Früher mal hatte das Ding auch Probleme mit mehrfach Vorkommenden Werten. Da musste man sicherstellen, dass vor der Abfrage Dupleten entfernt werden. Sonst kommt es aufgrund der Blockverarbeitung zu unnötigen Mahrfachabfragen.
Früher mal hatte das Ding auch Probleme mit mehrfach Vorkommenden Werten. Da musste man sicherstellen, dass vor der Abfrage Dupleten entfernt werden. Sonst kommt es aufgrund der Blockverarbeitung zu unnötigen Mahrfachabfragen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hallo,
Der SQL Trace sagt, dass da tatsächlich ein SELECT matnr, mara FROM... an die Datenbank geht (getestet auf einem halbwegs aktuellen S/4 und einem ECC EHP8 mit MaxDB)
Ist tatsächlich so. Habs grad mal überprüft:DeathAndPain hat geschrieben: ↑21.06.2023 16:08Ich könnte mir durchaus vorstellen, dass ABAP da gewisse Optimierungen eingebaut hat.
Code: Alles auswählen.
TYPES: BEGIN OF t_m,
matnr TYPE mara-matnr,
mtart TYPE mara-mtart,
END OF t_m.
DATA t TYPE STANDARD TABLE OF t_m.
SELECT * FROM mara INTO CORRESPONDING FIELDS OF TABLE t.
Folgende Benutzer bedankten sich beim Autor whaslbeck für den Beitrag (Insgesamt 2):
DeathAndPain • a-dead-trousers
Beitrag
von black_adept (Top Expert / 3950 / 105 /
886
)
»
Recht hast du - aber seit SAP die Inlinedeklarationen zulässt hast du das gleiche Problem mit (impliziten) DATA-Anweiseungen, die jetzt über den Code verstreut werden. Aus diesem Grund habe ich inzwischen auch kein Problem mehr damit TYPES-Anweisungen weiter hinten zu platzieren wenn es notwendig ist. ( Und ja - üblicherweise packe ich die recht weit zum Anfang des Codings )DeathAndPain hat geschrieben: ↑15.06.2023 19:59Das finde ich aber richtig eklig, denn dann hast Du ja einen TYPES-Befehl inmitten der Routine anstatt am Anfang. Sowas wäre bei mir bestenfalls als temporäre Krücke denkbar, aber niemals in einem finalen Code.black_adept hat geschrieben: ↑22.05.2023 13:41Code: Alles auswählen.
SELECT viele_felder FROM dbtab INTO TABLE @DATA(lt_data). TYPES: lts_data LIKE LINE OF lt_data, ltt_data TYPE HASHED TABLE OF lts_data WITH UNIQUE KEY keyfield(s). DATA(lt_data2) = CORRESPONDING ltt_data( lt_data ).
Beitrag
von black_adept (Top Expert / 3950 / 105 /
886
)
»
Was ist mit spaltenoptimierten DBs wie HANA, wo es jetzt doch wieder wichtig ( naja - m.E. weit weniger als SAP es immer hinstellt ) wird möglichst nur die Felder anzusprechen die man haben will?DeathAndPain hat geschrieben: ↑21.06.2023 16:08Also als ich im Jahre 2001 mit ABAP angefangen habe, da hat es noch richtig wahrnehmbar einen Unterschied gemacht, wie viele Spalten man aus einer Tabelle gelesen hat und wie viele Daten dementsprechend zu bewegen waren.
In den letzten Jahren ist das aber unter die Wahrnehmungsschwelle gerutscht. Ein sauberer, gut les- und wartbarer Code ist wesentlich wertvoller.
Beitrag
von black_adept (Top Expert / 3950 / 105 /
886
)
»
Alternative für ALL ENTRIES in recht neuen Releases ist auch die Möglichkeit eine interne Tabelle als Datenquelle im SELECT zuzulassen und dann mittels JOIN weiterzuarbeiten.a-dead-trousers hat geschrieben: ↑21.06.2023 17:13Und wenn man es schafft den FOR ALL ENTRIES IN wegzulassen und stattdessen z.B. RANGE Tabellen oder ähnliches zu verwenden, wird das ganze noch schneller.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
sap_enthusiast • a-dead-trousers
Beitrag
von DeathAndPain (Top Expert / 1806 / 214 /
396
)
»
Aus diesem Grunde habe ich anfangs auch gezögert, diese einzusetzen, aber die Vorteile überwiegen die Nachteile, weil der Code durch (vernünftige) Inline-Deklarationen kürzer und zugleich besser lesbar wird. Erst recht, wenn man sich an der SAP-Empfehlung orientiert, Inline-Deklarationen nur lokal einzusetzen (was ich meist tue, nur nicht beim Holen von Daten aus funktionalen Methoden - der Komfort, zusammen mit den Ergebniswerten auch die Typdeklaration implizit mitgeliefert zu bekommen, ist einfach zu kolossal. Und für lesbar halte ich es auch, wenn man auf dem Zielfeld in Eclipse Strg+Klick macht und damit zum Methodenaufruf springt, durch den klar ist, dass dies ein Feld ist, das über den Rückgabewert dieser Methode deklariert wird).black_adept hat geschrieben: ↑22.06.2023 12:20Recht hast du - aber seit SAP die Inlinedeklarationen zulässt hast du das gleiche Problem mit (impliziten) DATA-Anweiseungen, die jetzt über den Code verstreut werden.
Darüber mache ich mir Gedanken, wenn ich mal eine in den Fingern habe. 😁 Wobei, wenn selbst der herkömmliche SELECT diese Syntax optimiert und bei INTO CORRESPONDING FIELDS OF TABLE nur die benötigten Spalten an die Datenbank übermittelt, dann sollte die HANA-Implementierung das eigentlich auch können.
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
2540
Views
Views
Select into table @data(xxx) und returning Parameter
von Basler84 » 06.08.2018 18:40 • Verfasst in ABAP Objects®
von Basler84 » 06.08.2018 18:40 • Verfasst in ABAP Objects®
1
Antw.
Antw.
722
Views
Views
Select mit Aggregatsfunktion into @data(var)
von Temeraire » 12.06.2019 16:21 • Verfasst in ABAP® für Anfänger
von Temeraire » 12.06.2019 16:21 • Verfasst in ABAP® für Anfänger
6
Antw.
Antw.
36313
Views
Views
SELECT INTO und SELECT INTO TABLE Unterschied
von beterman » 17.01.2012 18:13 • Verfasst in ABAP® für Anfänger
von beterman » 17.01.2012 18:13 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
1087
Views
Views
17
Antw.
Antw.
4360
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
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.