INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Hi zusammen

Interessante Diskussion. Habe das Programm von D&P aufs Wesentliche reduziert und SAT-fähig gemacht.

Gruss
tm

REPORT.

PARAMETERS entries TYPE i OBLIGATORY DEFAULT 1000000.

CLASS lcl_report DEFINITION.

PUBLIC SECTION.

CLASS-METHODS main.

PRIVATE SECTION.

CLASS-DATA:
standard_table TYPE STANDARD TABLE OF i,
sorted_table TYPE SORTED TABLE OF i WITH UNIQUE DEFAULT KEY,
hashed_table TYPE HASHED TABLE OF i WITH UNIQUE DEFAULT KEY.

CLASS-METHODS:
create_standard_table,
create_sorted_table,
create_hashed_table,
search_standard_table,
search_sorted_table,
search_hashed_table.

ENDCLASS.

CLASS lcl_report IMPLEMENTATION.

METHOD main.

create_standard_table( ).
create_sorted_table( ).
create_hashed_table( ).

search_standard_table( ).
search_sorted_table( ).
search_hashed_table( ).

ENDMETHOD.

METHOD create_standard_table.
standard_table = VALUE #( FOR i = 1 UNTIL i > entries ( i ) ).
ENDMETHOD.

METHOD create_sorted_table.
sorted_table = VALUE #( FOR i = 1 UNTIL i > entries ( i ) ).
ENDMETHOD.

METHOD create_hashed_table.
hashed_table = VALUE #( FOR i = 1 UNTIL i > entries ( i ) ).
ENDMETHOD.

METHOD search_standard_table.
DATA(row) = standard_table[ table_line = entries ].
ENDMETHOD.

METHOD search_sorted_table.
DATA(row) = sorted_table[ table_line = entries ].
ENDMETHOD.

METHOD search_hashed_table.
DATA(row) = hashed_table[ table_line = entries ].
ENDMETHOD.

ENDCLASS.

START-OF-SELECTION.

lcl_report=>main( ).

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Also ich habe eher User-Cases, wo ich richtige Tabellen lesen und verarbeiten muss. Und da ist mein Beispiel deutlich überlegen.
Aber trotzdem Danke für dein Quellcode. Das zeigt mir, dass Tabellen mit weniger komplexen Daten schneller sortiert verarbeitet werden können.

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

nickname8 hat geschrieben:Also ich habe eher User-Cases, wo ich richtige Tabellen lesen und verarbeiten muss. Und da ist mein Beispiel deutlich überlegen.
Aber trotzdem Danke für dein Quellcode. Das zeigt mir, dass Tabellen mit weniger komplexen Daten schneller sortiert verarbeitet werden können.

In deinem Testprogramm ist das Befüllen der sorted table gegenüber der hashed table langsamer, weil die Daten von einer unsortierten Tabelle kopiert werden. Wenn die Daten bereits im SQL sortiert werden, ist die Erzeugung der sorted table schneller.

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

tm987456 hat geschrieben:In deinem Testprogramm ist das Befüllen der sorted table gegenüber der hashed table langsamer, weil die Daten von einer unsortierten Tabelle kopiert werden. Wenn die Daten bereits im SQL sortiert werden, ist die Erzeugung der sorted table schneller.

Falls das so sein sollte, müsste man dennoch fairerweise die Rechenzeit für die vorhergehende Sortierung draufrechnen, und dann geht die Rechnung auch wieder nicht auf. Aber das Ausschlaggebende scheint ja nicht zu sein, ob die Quelldaten sortiert reinkommen, sondern ob die interne Tabelle Felder enthält, die nicht Teil des Schlüssels sind! Idiotisch, aber offenbar Tatsache.

nickname8 hat geschrieben:Habe auch zusätzlich zu dem kerneligen zuweisen der Tabellen mit '=' per LOOP und INSERT den Tabelleninhalt von der STANDARD TABLE kopiert. Da war die HASHED TABLE ebenfalls schneller. Das nur fürs Protokoll

Ja, das habe ich auch getestet. Das wäre eigentlich die naheliegende Erklärung gewesen, aber leider ist es das nicht, sondern es liegt nur daran, ob die Tabelle noch Spalten hat, die nicht zum Schlüssel gehören. Was diese Frage mit hashed/sorted zu tun haben soll, kann wohl nur Horst Keller beantworten. Wenn, dann hätte ich erwartet, dass mit steigender Feldanzahl das Befüllen der Hashed-Tabelle langsamer wird, da mehr Felder zu hashen sind. Doch das Gegenteil ist der Fall. Wobei eben auch nicht die Zahl der Felder ausschlaggebend ist, sondern allein die boolesche Frage, ob es in der internen Tabelle auch Nichtschlüsselfelder gibt oder nicht.

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

So, ich möchte gerne hier nochmal eine Idee in die Runde werfen.

Ich hab nun auf einer anderen Seite gelesen, das For all entries bei einer Menge von 5000 ziemlich langsam wird.

Wie stehen die Meinungen mit Open Cursor zu operieren?

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

DeathAndPain hat geschrieben: Das macht ABAP automatisch; man legt es als Profilparameter fest. Bei Oracle ist der empfohlene Wert 5, also wird je 5 Einträgen ein neuer SELECT abgesetzt.

Deshalb ist es wichtig die doppelten Felder aus der Treibertabelle zu eliminieren. (Range aufbauen oder Treibertabelle kopieren, sortieren und Duplikate löschen)
Sonst könntest du den selber Datensatz mehrfach in den erwähnten verschiedenen SELECTs holen und das ist ja nicht Ziel der Sache.

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Bright4.5 hat geschrieben:Wie kann ich so einen Full Table Scan vermeiden? Anstatt "NOT IN" einfach umdrehen und mit "IN" Verfahren?

Bei einem "Full Table Scan" müssen ALLE Zeilen einer DB-Tabelle verglichen werden. Das NOT IN ist insofern schlecht, da ein NICHT TEIL einer Menge von Werten in den meisten Datenbanksystemen einen solchen FTS auslösen. Es sei denn, dass eine andere WHERE-Bedingung der SELECT-Anweisung die Menge soweit einschränkt, dass ein FTS nicht mehr notwendig ist.

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Bright,

was für Suchkriterien keinen Sinn machen, kannst Du Dir immer recht einfach selber erschließen, wenn Du Dir vorstellst, dass Deine Daten in einem (nach dem Primärschlüssel Deiner Tabelle sortierten) Telefonbuch stehen und Du händisch darin suchen möchtest.

Wenn ich Dir sage: Suche die Rufnummern aller Menschen mit dem Nachnamen "Meier" und dem Vornamen "Hans", dannn wirst Du das (alphabetisch sortierte) Buch schon in etwa an der richtigen Stelle aufschlagen und trotz 1000 Seiten schnell zu einem Ergebnis kommen.

Wenn ich Dir aber sage: Suche die Rufnummern aller Menschen, deren Nachname nicht mit S oder V anfängt, dann wird das schon bedeutend schwieriger. Wenn Du vermeiden willst, das Telefonbuch von vorne nach hinten Name für Name durchzugehen (das wäre ein "Full Table Scan"), dann musst Du Dir meine NOT-Anforderung in eine Anforderung ohne NOT umbauen, also sagen, dass Du stattdessen A bis R und dann noch T bis U und dann noch W bis Z suchen musst. Wie adt angedeutet hat, sind die meisten Datenbanksysteme nicht so clever, dass sie sich diese Umformung aus dem Index selber herleiten können, also bleibt ihnen als Alternative nur der Full Table Scan. Willst Du diesen vermeiden, dann mache die Umformung lieber in Deinem Programm und liefere der Datenbank eine positiv formulierte WHERE-Bedingung.

Hier zickt er leider immer bei dem 'IN' rum. Ein '=' würde gehen, allerdings kein 'IN'.
Weiß jemand wie man sowas umgehen kann? Oder wie man es anders lösen kann?

Der ON-Operator hat diverse syntaktische Einschränkungen. Ich rechne damit, dass Du Dein Problem lösen kannst, indem Du Deine Bedingung einfach in den WHERE-Block schreibst. Das ist auch inhaltlich richtiger: Der ON-Block soll nur die Kriterien enthalten, über die die gejointe Tabelle mit der Haupttabelle verknüpft ist. Bei Deinem IN-Operator prüfst Du aber nicht gegen diese, sondern gegen eine interne ABAP-Tabelle.

Also:

left Outer join Tiban AS z
ON p1~iban = z~iban
INTO TABLE @it_Ergebnis
WHERE p1~valid_from IN @so_valid_from
AND z~ERNAM IN @so_ernam.