SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Probiers mal so: Da du die 'addrnumber' und die 'address_id' sowieso gleich setzt, brauchst du das Ganze doch nicht zweimal im SELECT.

EDIT:
Okay... du willst auch den BP im SELECT haben... Die zweite Query war dann aber mit dem falschen Feld.

Dein zweiter Ansatz schaut schon ziemlich richtig aus. Zur Optimierung würde ich nun nur noch das SELECT, das dir die Tabelle für den FOR ALL ENTRIES befüllt, in die Query miteinbauen, dann läuft das schon sehr performant ab.
(FOR ALL ENTRIES ist bei großen Datenmengen eine nicht zu unterschätzende Performance Krüke)
Zur Optimierung würde ich den JOIN in einen DB-View oder CDS-View auslagern und dann sollte das auch im Programmcode "schön" ausschauen (ohne die ganzen @, ~ usw.)

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

tm987456 hat geschrieben: ↑

21.10.2020 09:06

Das heisst, du würdest, obwohl du bereits alle Business Partner IDs und zugehörigen Adressen IDs in einer internen Tabelle hast, alles mit zwei Joins neu lesen, um den FOR ALL ENTRIES zu vermeiden?

Jein. Ich würde die Query die die Business Partner IDs und zugehörigen Adressen IDs ermittelt mit der zweiten Query verknüpfen WENN ES SINN macht.
Da ich aus deinem bisherigen Coding nichts Gegenteiliges herausgelesen hab, würde es für mich Sinn machen. ;)

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Ja perfekt. Genau sowas habe ich gesucht. Danke!
Macht es Sinn prinzipiell FOR ALL ENTIRES Situationen durch den Join zu ersetzten? Performance sollte ja auch besser sein.

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Macht es Sinn prinzipiell FOR ALL ENTIRES Situationen durch den Join zu ersetzten? Performance sollte ja auch besser sein.

Das kann ich mir, ehrlich gesagt, nicht vorstellen. Was ABAP da macht, kann ja kein echter JOIN auf Datenbankebene sein, denn die Datenbank kennt die interne Tabelle nicht. Also kann ABAP ja nichts anderes machen, als die Werte aus der internen Tabelle einzeln an die Datenbank zu übertragen, vermutlich als WHERE fraglicher_wert IN (wert1,wert2,wert3,...). Genau das macht aber auch der FOR ALL ENTRIES IN. Von daher halte ich es performancetechnisch für ein Nullsummenspiel. Müsste man mal austesten, was da schneller ist.

Die Diskussion mit adt habe ich nicht wirklich verstanden, weil da zu abstrakt (also ohne konkreten Code) argumentiert wurde. Ich verstehe aber auch nicht, wie in Deinem ursprünglichen Posting

Gelöst habe ich das wie folgt:

Code: Alles auswählen.

    SELECT addrnumber, smtp_addr FROM adr6
      FOR ALL ENTRIES IN @address_ids
      WHERE addrnumber = @address_ids-address_id
      INTO @DATA(email_address).

      email_addresses = VALUE #( BASE email_addresses
        (
          address_id = email_address-addrnumber
          business_partner_id = address_ids[ address_id = email_address-addrnumber ]-business_partner_id
          email_address = email_address-smtp_addr
        )
      ).
    ENDSELECT.

äquivalent sein soll zu

So würde es gehen, aber ein eigentlich unnötiger Join.

Code: Alles auswählen.

    SELECT a~partner, b~addrnumber, b~smtp_addr FROM but021_fs AS a
      JOIN adr6 AS b ON b~addrnumber = a~addrnumber
      FOR ALL ENTRIES IN @std_address_ids
      WHERE a~partner = @std_address_ids-business_partner_id
        AND b~addrnumber = @std_address_ids-address_id
      INTO TABLE @DATA(email_address2).

Das kann doch eigentlich gar nicht sein, denn in der zweiten Version liest Du eine ganz andere Datenbanktabelle als in der ersten?! Es sei denn, es gibt zwischen den Inhalten dieser Datenbanktabellen Konsistenzabhängigkeiten, die ich nicht kenne (die Tabelle but021_fs sehe ich zum ersten Mal).

Ich hätte folgendes gemacht:
Ob das tatsächlich langsamer ist als der JOIN über die interne Tabelle, das wäre nochmal nachzuprüfen; da bin ich keineswegs überzeugt. Ich räume allerdings ein, dass der JOIN kosmetisch schöner ist. Viel nimmt es sich in meinen Augen aber nicht.

Bei Deiner Lösung (in Deinem ursprünglichen Post) fehlt mir (wie leider in so vielen Frageposts) die Typisierung der verwendeten Felder und Tabellen. Vor allem wäre interessant gewesen, wie Deine interne Tabelle address_ids deklariert ist. Wenn die nicht SORTED oder HASHED über die Spalte address_id ist, dann machst Du bei jedem Durchlauf Deiner SELECT-Schleife eine sequenzielle Suche über die address_ids. Dass das nicht performant sein kann, liegt auf der Hand.

Was mir auch nicht gefällt, ist Dein Tabellenaufbau über VALUE #( BASE email_addresses ... . Technisch gesehen erzeugst Du damit bei jedem einzelnen Schleifendurchlauf eine komplett neue interne Tabelle. (Wenn die Zieltabelle email_addresses sortiert oder gehasht ist, dann baut er dabei zudem jedesmal komplett neu die Sortierung bzw. Hashung auf!) Das halt ich nicht nur für unperformant, sondern auch beim Lesen für schwerer zu verstehen als die Notation:
Letztlich willst Du bei jedem Schleifendurchlauf ja nur eine Zeile an Deine bereits aufgebaute interne Tabelle anhängen. Mit diesem APPEND tust Du das technisch und zeigst zugleich dem Leser Deines Codes deutlich, dass Du genau das tun willst.

Ich bin auch kein Fan davon, dass Du Deine Ergebnistabelle email_adresses (auch in der letzten Lösung) per Inline-Deklaration erzeugst. Das wäre allenfalls dann ok, wenn Du diese Tabelle anschließend als ALV oder anderweitig so, wie sie ist, ausgeben möchtest. Ich vermute aber, dass Du sie im weiteren Verlauf nutzen möchtest, um per
zu verschiedenen Leuten die Emailadresse zu holen. Und dann ist es Mist, wenn email_addresses eine unsortierte Standardtabelle ist. Das sollte einem dann schon die paar Zeilen Code für eine konventionelle Deklaration wert sein.

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Horst Keller über value:
https://blogs.sap.com/2014/09/29/abap-n ... pressions/
Damit wird es wohl zukünftig wieder APPEND. Danke D&P!

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

DeathAndPain hat geschrieben: ↑

26.10.2020 17:56

{rant}Dementsprechend braucht man davor auch keinen CLEAR. Das regt mich immer auf, wenn ich sehe, wie manche Leute aus panischer Angst, mit alten Feldwerten weiterzuarbeiten, ihren Code mit sinnlosen CLEAR-Befehlen zukleistern. Insbesondere ist jeder CLEAR vor einer direkten Zuweisung wie dieser für die Katz (außer wenn die Zielvariable auch auf der rechten Seite der Zuweisung auftaucht, was in Deinem BASE-Fall natürlich der Fall wäre). Für mich hat das auch eine meinungsbildende Bedeutung. Wenn ich:

Code: Alles auswählen.

CLEAR abc.
abc = def(4) && `01`.

sehe, dann schließe ich daraus, dass ich Code eines Programmierers vor mir habe, der in blind eingehämmerten Mustern programmiert, anstatt darüber nachzudenken, was er schreibt. Aber ich schweife ab. Du hast Dir in dieser Richtung ja nichts zuschulden kommen lassen. 😊{/rant}

Wobei mir Leute lieber sind, die vorsichtshalber ein CLEAR schreiben als solche die es dann mal irgendwo vergessen wo es wichtig ist. Wahrscheinlich ist das einfach im Muskelgedächtnis der Finger verankert.
Und ich frage mich gerade wie gut der Compiler von ABAP ist - der könnte solch ein offensichtlich überflüssiges Konstrukt doch intern optimieren.

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

ewx hat geschrieben: ↑

27.10.2020 11:56

AbapOpenChecks - CHECK_79 - CLEAR as first use of variable

Wer legt denn so einen sinnlosen Check an? Habe selten etwas Überflüssigeres gesehen.
Dass so eine Prüfung sehr gut in anderen Programmiersprachen zu gebrauchen ist welche nicht mit impliziter Initialisierung wie ABAP ( z.B. Java ) arbeiten steht außer Frage - aber dieses Konzept auf ABAP übertragen zu wollen scheint auf ein Unwissen dieser ABAP-Eigenschaft hinzudeuten.