INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE
Hey,
ich bin gerade dabei ein Programm performanter zu gestalten, da es zu langsam läuft.
Ich hab hier bei einem Inner join (Select) ein Into Corresponding Fields of table eingebaut. Ich hab glaub ich damals gelernt Into Table sei deutlich performanter (schneller). Irgendwelche Meinungen dazu ??
Into Table sollte deutlich schneller sein, oder?
ich bin gerade dabei ein Programm performanter zu gestalten, da es zu langsam läuft.
Ich hab hier bei einem Inner join (Select) ein Into Corresponding Fields of table eingebaut. Ich hab glaub ich damals gelernt Into Table sei deutlich performanter (schneller). Irgendwelche Meinungen dazu ??
Into Table sollte deutlich schneller sein, oder?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von Tommy Nightmare (ForumUser / 28 / 5 /
1
)
»
Beim "INTO CORRESPONDING" gibt es noch den zusätzlichen Schritt, die passenden Zielfelder zu suchen, ohne das "CORRESPONDING" wird das nicht geprüft.
Wenn die angegebene Tabelle hinter "INTO" dann den falschen Typ hast, hast du als Ergebnis natürlich nichts sinnvolles.
Aber lass es uns mal testen:
In meinem Beispiel lief der Select mit "INTO CORRESPONDING" immer ca. 2,5 mal länger.
Ich würde also von immer empfehlen, die zu selektierenden Felder in die Select Liste zu schreiben und das "CORRESPONDING" wegzulassen.
In den meisten Fällen weiß man ja vorher schon, welche Felder man braucht.
LG Tommy
Wenn die angegebene Tabelle hinter "INTO" dann den falschen Typ hast, hast du als Ergebnis natürlich nichts sinnvolles.
Aber lass es uns mal testen:
Code: Alles auswählen.
DATA t_t002 TYPE TABLE OF t002.
GET RUN TIME FIELD DATA(t0).
SELECT *
FROM t002
INTO CORRESPONDING FIELDS OF TABLE t_t002.
GET RUN TIME FIELD DATA(t1).
CLEAR t_t002.
GET RUN TIME FIELD DATA(t2).
SELECT spras laspez lahq laiso
FROM t002
INTO TABLE t_t002.
GET RUN TIME FIELD DATA(t3).
DATA(r0) = t1 - t0.
DATA(r1) = t3 - t1.
WRITE:
r0, /, r1.
Ich würde also von immer empfehlen, die zu selektierenden Felder in die Select Liste zu schreiben und das "CORRESPONDING" wegzulassen.
In den meisten Fällen weiß man ja vorher schon, welche Felder man braucht.
LG Tommy
Es ist in der Tat ein wenig langsamer, weil die richtigen Daten gemappt werden müssen. Aber dies ist nicht die erste Stellschraube, an der gedreht werden sollte wenn es um Performance geht.
Eher
Datenbankzugriffe optimieren
- richtiger Index genutzt?
- nur die benötigten Felder übertragen?
- sortierung auf db ausgelagert? (wenn nötig)
- FAE und Ranges sortieren/duplikate löschen
Itab-Zugriffe optimiert
- sortierte oder noch besser hashed tabellen nutzen
- in loops mit fiel-symbols arbeiten
- keine sorts und db-zugriffe in einem loop
- sortierte Schlüssel für where-bedingungen bei loops verwenden und keine OR-Verknüpfungen
nur so paar Anhaltspunkte
Eher
Datenbankzugriffe optimieren
- richtiger Index genutzt?
- nur die benötigten Felder übertragen?
- sortierung auf db ausgelagert? (wenn nötig)
- FAE und Ranges sortieren/duplikate löschen
Itab-Zugriffe optimiert
- sortierte oder noch besser hashed tabellen nutzen
- in loops mit fiel-symbols arbeiten
- keine sorts und db-zugriffe in einem loop
- sortierte Schlüssel für where-bedingungen bei loops verwenden und keine OR-Verknüpfungen
nur so paar Anhaltspunkte
Bei mir ist es grade so, dass ohne CORRESPONDING viel länger dauert. Ich war aber auch so frei dein Testprogramm dahingehend zu ändern, das erst der Select ohne CORRESPONDING aufgerufen wird und dann erst der mit.Tommy Nightmare hat geschrieben: In meinem Beispiel lief der Select mit "INTO CORRESPONDING" immer ca. 2,5 mal länger.
Ich würde also von immer empfehlen, die zu selektierenden Felder in die Select Liste zu schreiben und das "CORRESPONDING" wegzulassen.
In den meisten Fällen weiß man ja vorher schon, welche Felder man braucht.
LG Tommy
Ich denke du kommst selber drauf, warum das so ist
Beitrag
von Tommy Nightmare (ForumUser / 28 / 5 /
1
)
»
Wenn ich immer einen Select auskommentiere, ist der ohne "CORRESPONDING" trotzdem eher schneller.
Trotzdem ist der erste Select von beiden immer langsamer, anscheinend wird das irgendwie gepuffert...
Trotzdem ist der erste Select von beiden immer langsamer, anscheinend wird das irgendwie gepuffert...
Wird es.Tommy Nightmare hat geschrieben:anscheinend wird das irgendwie gepuffert...
https://ibb.co/HGR3XmF
Datenbankzugriffe optimieren
- richtiger Index genutzt?
- nur die benötigten Felder übertragen?
- sortierung auf db ausgelagert? (wenn nötig)
- FAE und Ranges sortieren/duplikate löschen
Itab-Zugriffe optimiert
- sortierte oder noch besser hashed tabellen nutzen
- in loops mit fiel-symbols arbeiten
- keine sorts und db-zugriffe in einem loop
- sortierte Schlüssel für where-bedingungen bei loops verwenden und keine OR-Verknüpfungen
vielen Dank für deine Anhaltspunkte. Ich hab jetzt schon mal auf Into Table abgeändert. Hat vielleicht ein bisschen was gebracht, aber nicht wirklich merklich. Ich teste die Zeit mit get run time field. Leider sind dort die Zeiten aufgrund der Auslastung auch unterschiedlich, deshalb kann es auch nur grob bestimmt werden, ob es nun wirklich schneller geworden ist, lässt sich wenn dann nur minimal festhalten.
Bin gerade mal dabei deine anderen Punkte am abarbeiten.
- richtiger Index genutzt?
- nur die benötigten Felder übertragen?
- sortierung auf db ausgelagert? (wenn nötig)
- FAE und Ranges sortieren/duplikate löschen
Itab-Zugriffe optimiert
- sortierte oder noch besser hashed tabellen nutzen
- in loops mit fiel-symbols arbeiten
- keine sorts und db-zugriffe in einem loop
- sortierte Schlüssel für where-bedingungen bei loops verwenden und keine OR-Verknüpfungen
vielen Dank für deine Anhaltspunkte. Ich hab jetzt schon mal auf Into Table abgeändert. Hat vielleicht ein bisschen was gebracht, aber nicht wirklich merklich. Ich teste die Zeit mit get run time field. Leider sind dort die Zeiten aufgrund der Auslastung auch unterschiedlich, deshalb kann es auch nur grob bestimmt werden, ob es nun wirklich schneller geworden ist, lässt sich wenn dann nur minimal festhalten.
Bin gerade mal dabei deine anderen Punkte am abarbeiten.
Wie ist das bitte zu verstehen?- sortierung auf db ausgelagert? (wenn nötig)
Ist es nicht mehr so, dass man die DB (als Flaschenhals) weitestgehend entlasten sollte? Außer man kann z.B. durch Aggregatfunktionen (SUM) die Anzahl der Ergebnismenge deutlich reduzieren.
Dem Flaschenhals ist es egal, ob die Daten sortiert oder unsortiert hindurch gehen... 
Die Datenbankzugriffe + Datenmenge sollte minimiert werden.
Ansonsten darf man die Datenbank gerne arbeiten lassen...
Die Datenbankzugriffe + Datenmenge sollte minimiert werden.
Ansonsten darf man die Datenbank gerne arbeiten lassen...
Mit dem Code-To-Data oder auch Code-Pushdown Ansatz geht es darum, der Datenbank so viel Arbeit wie möglich zu überlassen.
Die DB ist ja - kezerisch gesprochen - nur ein Datengrab. Die CPU hat im Gegensatz zum Applikationsserver vergleichsweise wenig zu tun. Da ist der Flaschenhals eher der Datendurchsatz als die CPU.
Die DB ist ja - kezerisch gesprochen - nur ein Datengrab. Die CPU hat im Gegensatz zum Applikationsserver vergleichsweise wenig zu tun. Da ist der Flaschenhals eher der Datendurchsatz als die CPU.
Klar, dafür ist sie ja da.Ansonsten darf man die Datenbank gerne arbeiten lassen...
Aber man sollte sie nicht unnötig belasten. Man hat nur einen DB-Server und ggf. mehrere Applikation-Server. Verteilung der Last ist immer gut. Wird der DB-Server mit Aufgaben beschäftigt, die genauso gut auch auf den Applikation-Servern gemacht werden können, dann belastet man die zentrale DB-Instanz als potentiellen Flaschenhals unnötig. Sortierung ist da ein gutes Beispiel.
Wahrscheinlich können wir da tagelang herumdiskutieren, was wann wie unter welchen Umständen besser ist.
Letztendlich tut es sich wahrscheinlich nicht viel, ob die Tabelle von der DB oder von der Applikation sortiert wird. Kommt wahrscheinlich sehr auf die Größe drauf an.
Lastverteilung: Deswegen soll die DB ja IMHO gerne sortieren. Die Applikation übernimmt ja bereits die Last der Verarbeitung...
Letztendlich tut es sich wahrscheinlich nicht viel, ob die Tabelle von der DB oder von der Applikation sortiert wird. Kommt wahrscheinlich sehr auf die Größe drauf an.
Lastverteilung: Deswegen soll die DB ja IMHO gerne sortieren. Die Applikation übernimmt ja bereits die Last der Verarbeitung...
So.
Also Feldsymbole bei Loops benutze ich.
Die Tabellen sind sortiert und Duplikate gelöscht.
Hashed-Tabellen funktioniert leider nicht, da ich Indexoperationen im Programm vollziehe.
Es verursacht vor allem an dieser Stelle einen Timeout:
SELECT p~lifnr p~laufd p~vblnr p~name1 p~pstlz
p~stras p~zbnkn p~zswif
FROM reguh AS p
INNER JOIN regup AS k
ON p~lifnr = k~lifnr
INTO TABLE it_regh_up
FOR ALL ENTRIES IN it_regp_kp
WHERE k~xblnr = it_regp_kp-xblnr
AND k~hkont NOT IN r_hkont
AND p~saknr = it_regp_kp-saknr
AND p~dmbtr <= IN so_ibst.
Dieses For all entries vielleicht umstellen/ersetzen???
Also Feldsymbole bei Loops benutze ich.
Die Tabellen sind sortiert und Duplikate gelöscht.
Hashed-Tabellen funktioniert leider nicht, da ich Indexoperationen im Programm vollziehe.
Es verursacht vor allem an dieser Stelle einen Timeout:
SELECT p~lifnr p~laufd p~vblnr p~name1 p~pstlz
p~stras p~zbnkn p~zswif
FROM reguh AS p
INNER JOIN regup AS k
ON p~lifnr = k~lifnr
INTO TABLE it_regh_up
FOR ALL ENTRIES IN it_regp_kp
WHERE k~xblnr = it_regp_kp-xblnr
AND k~hkont NOT IN r_hkont
AND p~saknr = it_regp_kp-saknr
AND p~dmbtr <= IN so_ibst.
Dieses For all entries vielleicht umstellen/ersetzen???
Hm, da sehe ich mehrere Probleme:
- REGUP ist eine Clustertabelle - da gibts keine zusätzlichen Indizes drauf
- p~saknr und p~dmbtr sind nicht Bestandteil irgendeines Schlüssels in der REGUH
Vielleicht gibts einen FuBa der optimiert auf die Tabelle REGUP zugreift.
Ich weiß nicht ob du mit einer Optimierung von FAE weiterkommst.
Kannst es ja versuchen: FAE sortieren und Duplikate löschen, bzw. zwei Ranges bauen. Aber für mich sieht es nach einem ziemlichen FULL TABLE SCAN aus...
Hat der Select schonmal im Produktivsystem funktioniert? Oder bisher immer in einen Timeout gelaufen.
Wie lange läuft der im Hintergrundmodus?
- REGUP ist eine Clustertabelle - da gibts keine zusätzlichen Indizes drauf
- p~saknr und p~dmbtr sind nicht Bestandteil irgendeines Schlüssels in der REGUH
Vielleicht gibts einen FuBa der optimiert auf die Tabelle REGUP zugreift.
Ich weiß nicht ob du mit einer Optimierung von FAE weiterkommst.
Kannst es ja versuchen: FAE sortieren und Duplikate löschen, bzw. zwei Ranges bauen. Aber für mich sieht es nach einem ziemlichen FULL TABLE SCAN aus...
Hat der Select schonmal im Produktivsystem funktioniert? Oder bisher immer in einen Timeout gelaufen.
Wie lange läuft der im Hintergrundmodus?
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
nickname8, Du solltest Deine Überzeugungen unbedingt sorgsamer mit der Realität abgleichen, bevor Du sie im Brustton der Überzeugung vorträgst. Was Du hier alles an zweifelhaften Behauptungen aufgestellt hast, geht auf keine Kuhhaut. Damit verunsicherst Du andere Anwender und schickst sie auf falsche Gleise.
Die Zahlen waren dergestalt, dass ich zu dem Ergebnis gekommen bin, dass sich abgesehen von exotischen Extremfällen hashed tables in realitätsnahen Programmen niemals lohnen.
Leider versaut einem dieses Datenbank-Caching weitgehend die Messmöglichkeiten. Es ist nämlich nicht nur so, dass der zweite SELECT dem ersten gegenüber im Vorteil ist. Startet man das Messprogramm ein weiteres Mal, dann sind die Tabellenzeilen oft immer noch gepuffert, so dass die Datenbank beide Anfragen aus ihrem Puffer beantwortet und man keine sinnvollen Messergebnisse bekommt. Erschwerend kommt hinzu, dass die Ausführungszeiten stark schwanken, was auch mit der Serverlandschaft zu tun hat. Meist handelt es sich ja um gehostete Server in virtuellen Umgebungen, bei denen mehrere virtuelle Server auf einer physischen Maschine sitzen. Da kann die Last von einer anderen virtuellen Maschine in einer Millisekunde hoch und in der nächsten gering sein, was einem die Messergebnisse verhagelt. Das kann man nur ausgleichen, indem man das Messprogramm oft hintereinander startet und die Ergebnisse mittelt. Leider wird man damit aber erst recht Opfer des Datenbankcachings. (Wenn jemand einen Datenbank-Hint für Sybase kennt, mit dem man dieses Caching zu Messzwecken umgehen kann, immer her damit.)
Dass der INTO TABLE, der die ganze von der Datenbank gelesene Datenstruktur platsch in die Zielstruktur schreibt, schneller ist als ein INTO CORRESPONDING FIELDS OF TABLE, liegt auf der Hand. Nach meiner Erfahrung ist der Unterschied aber so gering, dass ich noch nie einen Performanceunterschied wahrgenommen habe, wenn geänderte Programmanforderungen mich gezwungen habe, einen INTO TABLE in einen INTO CORRESPONDING FIELDS OF TABLE umzubauen. Was da an zusätzlicher Rechenzeit notwendig ist, ist ja rein im ABAP. Und wenn ich mir anschaue, was der durchschnittliche Programmierer sonst so an Performance verschenkt, etwa mit sinnlosen Befehlen... Sehr häufig liest man vor dem SELECT beispielsweise einen CLEAR bzw. REFRESH auf die zu füllende Tabelle. Eine völlig überflüssige Anweisung, da INTO TABLE (egal ob mit oder ohne CORRESPONDING) sowieso immer erst die Zieltabelle leert. Klar ist der Performanceverlust durch solch CLEAR gering und wird in aller Regel unterhalb der Wahrnehmungsschwelle liegen. Aber wenn wir über den Performancenachteil von INTO CORRESPONDING FIELDS OF TABLE gegenüber INTO TABLE reden, dann muss es auch erlaubt sein, sowas auf den Tisch zu bringen.
@Bright4.5: Dein SELECT ist eine ziemliche Katastrophe. Nicht nur, dass Du keinen auf den Tabellen REGUP und REGUH definierten Datenbankindex auch nur ansatzweise nutzt, Du verknüpfst die beiden Tabellen in Deinem JOIN auch nicht sinnvoll. Die haben ja zum größten Teil den gleichen Primärschlüssel. Zumindest diese Felder sollten alle in den ON-Teil des Joins rein, und dann sinnvolle Indexfelder in die WHERE-Bedingung. Ich möchte wetten, dass Performance nicht Dein einziges Problem ist, sondern dass dieser Join, wenn er denn mal fertig werden würde, Dir ohne Ende unerwünschte Kreuzprodukte (also im Sinne Deiner Aufgabenstellung falsche Ergebnisse) zurückliefern würde.
Ich kenne die beiden Tabellen nicht, da sie zu Modulen gehören, in denen ich nicht zu Hause bin, aber dennoch behaupte ich, dass die SAP sich was dabei gedacht hat, als sie die Primärschlüssel und sonstigen Tabellenindizes dieser Tabellen so festgelegt hat, wie sie festgelegt sind. Du solltest daher Deine Anforderung überprüfen, ob sie sich nicht damit in Einklang bringen lässt.
Wenn es gar nicht anders geht und der Zugriff unbedingt über diese Schlüsselfelder erfolgen soll, dann wäre der einzig mögliche Weg, die beiden Tabellen (möglichst reduziert auf die für Deinen Zugriff relevanten Spalten) komplett in interne Tabellen einzulesen, die Deiner Anforderung entsprechend sortiert sind, so dass Dein Programm gewissermaßen seinen eigenen Index im Hauptspeicher aufbaut. Danach würdest Du dann darüber loopen und hättest dank Deiner durchdachten internen Tabellenschlüsseldefinition eine vernünftige Zugriffszeit. Kostet natürlich Hauptspeicher, solch Tabellenkomplettpufferung in eigener interner Tabelle, wobei Du auch hier optimieren kannst, indem Du keine Zeilen in die Puffertabelle einliest, die Du auf keinen Fall brauchen wirst (z.B. solche aus längst vergangenen Jahren; das hängt vom Anwendungsfall ab). Sobald Du einen Suchzugriff über diese Spalten in mehr als einem Programm brauchst, ist die Anlage eines Datenbankindex angezeigt.
Ich habe auch mal geglaubt, dass hashed-Tabellen besser seien. Bis ich mir irgendwann mal die Mühe gemacht habe, ein Testprogramm zu schreiben und die Performance zu messen. (Irgendwo hier gibt es noch den Thread, in dem ich das Programm und meine Messergebnisse vorgestellt habe.) Das Ergebnis war, dass das Füllen der Hashtabelle (wohl wegen der Berechnung der Hashes) um so viel langsamer war, dass man hinterher Abertausende von Suchvorgängen brauchen würde, damit sich dieser Nachteil gegenüber einer sorted table amortisiert. Dabei nützt es auch nichts, von besonders großen Tabellen auszugehen. Bei denen ist der (geringe) Suchvorteil der hashed table zwar größer, dafür sind aber auch entsprechend mehr Hashes beim Befüllen der Tabelle zu berechnen.nickname8 hat geschrieben:- sortierte oder noch besser hashed tabellen nutzen
Die Zahlen waren dergestalt, dass ich zu dem Ergebnis gekommen bin, dass sich abgesehen von exotischen Extremfällen hashed tables in realitätsnahen Programmen niemals lohnen.
Die ABAP-Tabellenpufferung hat damit gar nichts zu tun, die ist nämlich nur bei Tabellen überschaubarer Größe (typischerweise Customizingtabellen) aktiviert, nicht bei den Anwendungsdatentabellen, auf die man in seinen Programmen meist zugreift. Der hier beschriebene Effekt tritt jedoch auch bei letzteren auf. Ursache ist, dass die Datenbanken selber auch puffern. Wer oft hintereinander auf dieselbe Tabelle oder gar dieselben Sätze der Tabelle zugreift, bekommt die späteren Zugriffe wesentlich schneller erledigt. Das ist nicht so schnell wie die ABAP-Tabellenpufferung, die SAP-serverseitig im Hauptspeicher erfolgt und schon gar nicht so schnell wie eine durchdacht programmierte Pufferung in einer sortierten internen Tabelle, aber es ist allemal drastisch schneller als ein erstmaliger Zugriff.nickname8 hat geschrieben:Wird es.Tommy hat geschrieben:anscheinend wird das irgendwie gepuffert...
https://ibb.co/HGR3XmF
Leider versaut einem dieses Datenbank-Caching weitgehend die Messmöglichkeiten. Es ist nämlich nicht nur so, dass der zweite SELECT dem ersten gegenüber im Vorteil ist. Startet man das Messprogramm ein weiteres Mal, dann sind die Tabellenzeilen oft immer noch gepuffert, so dass die Datenbank beide Anfragen aus ihrem Puffer beantwortet und man keine sinnvollen Messergebnisse bekommt. Erschwerend kommt hinzu, dass die Ausführungszeiten stark schwanken, was auch mit der Serverlandschaft zu tun hat. Meist handelt es sich ja um gehostete Server in virtuellen Umgebungen, bei denen mehrere virtuelle Server auf einer physischen Maschine sitzen. Da kann die Last von einer anderen virtuellen Maschine in einer Millisekunde hoch und in der nächsten gering sein, was einem die Messergebnisse verhagelt. Das kann man nur ausgleichen, indem man das Messprogramm oft hintereinander startet und die Ergebnisse mittelt. Leider wird man damit aber erst recht Opfer des Datenbankcachings. (Wenn jemand einen Datenbank-Hint für Sybase kennt, mit dem man dieses Caching zu Messzwecken umgehen kann, immer her damit.)
Dass der INTO TABLE, der die ganze von der Datenbank gelesene Datenstruktur platsch in die Zielstruktur schreibt, schneller ist als ein INTO CORRESPONDING FIELDS OF TABLE, liegt auf der Hand. Nach meiner Erfahrung ist der Unterschied aber so gering, dass ich noch nie einen Performanceunterschied wahrgenommen habe, wenn geänderte Programmanforderungen mich gezwungen habe, einen INTO TABLE in einen INTO CORRESPONDING FIELDS OF TABLE umzubauen. Was da an zusätzlicher Rechenzeit notwendig ist, ist ja rein im ABAP. Und wenn ich mir anschaue, was der durchschnittliche Programmierer sonst so an Performance verschenkt, etwa mit sinnlosen Befehlen... Sehr häufig liest man vor dem SELECT beispielsweise einen CLEAR bzw. REFRESH auf die zu füllende Tabelle. Eine völlig überflüssige Anweisung, da INTO TABLE (egal ob mit oder ohne CORRESPONDING) sowieso immer erst die Zieltabelle leert. Klar ist der Performanceverlust durch solch CLEAR gering und wird in aller Regel unterhalb der Wahrnehmungsschwelle liegen. Aber wenn wir über den Performancenachteil von INTO CORRESPONDING FIELDS OF TABLE gegenüber INTO TABLE reden, dann muss es auch erlaubt sein, sowas auf den Tisch zu bringen.
Auf was für einem alten Release sitzt Du? Die SAP stellt Clustertabellen nach und nach auf transparente Tabellen um, und auf meinem 7.50 ist die REGUP auch eine transparente Tabelle. Weitere Indizes sind trotzdem nicht darauf definiert, aber das könnte man notfalls selber machen. Sollte man natürlich möglichst vermeiden, weil es bei großen Tabelle viel Speicherplatz und auch etwas Rechenzeit kostet.nickname8 hat geschrieben:- REGUP ist eine Clustertabelle - da gibts keine zusätzlichen Indizes drauf
@Bright4.5: Dein SELECT ist eine ziemliche Katastrophe. Nicht nur, dass Du keinen auf den Tabellen REGUP und REGUH definierten Datenbankindex auch nur ansatzweise nutzt, Du verknüpfst die beiden Tabellen in Deinem JOIN auch nicht sinnvoll. Die haben ja zum größten Teil den gleichen Primärschlüssel. Zumindest diese Felder sollten alle in den ON-Teil des Joins rein, und dann sinnvolle Indexfelder in die WHERE-Bedingung. Ich möchte wetten, dass Performance nicht Dein einziges Problem ist, sondern dass dieser Join, wenn er denn mal fertig werden würde, Dir ohne Ende unerwünschte Kreuzprodukte (also im Sinne Deiner Aufgabenstellung falsche Ergebnisse) zurückliefern würde.
Ich kenne die beiden Tabellen nicht, da sie zu Modulen gehören, in denen ich nicht zu Hause bin, aber dennoch behaupte ich, dass die SAP sich was dabei gedacht hat, als sie die Primärschlüssel und sonstigen Tabellenindizes dieser Tabellen so festgelegt hat, wie sie festgelegt sind. Du solltest daher Deine Anforderung überprüfen, ob sie sich nicht damit in Einklang bringen lässt.
Wenn es gar nicht anders geht und der Zugriff unbedingt über diese Schlüsselfelder erfolgen soll, dann wäre der einzig mögliche Weg, die beiden Tabellen (möglichst reduziert auf die für Deinen Zugriff relevanten Spalten) komplett in interne Tabellen einzulesen, die Deiner Anforderung entsprechend sortiert sind, so dass Dein Programm gewissermaßen seinen eigenen Index im Hauptspeicher aufbaut. Danach würdest Du dann darüber loopen und hättest dank Deiner durchdachten internen Tabellenschlüsseldefinition eine vernünftige Zugriffszeit. Kostet natürlich Hauptspeicher, solch Tabellenkomplettpufferung in eigener interner Tabelle, wobei Du auch hier optimieren kannst, indem Du keine Zeilen in die Puffertabelle einliest, die Du auf keinen Fall brauchen wirst (z.B. solche aus längst vergangenen Jahren; das hängt vom Anwendungsfall ab). Sobald Du einen Suchzugriff über diese Spalten in mehr als einem Programm brauchst, ist die Anlage eines Datenbankindex angezeigt.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Legxis
Vergleichbare Themen
2
Antw.
Antw.
13703
Views
Views
„INTO CORRESPONDING FIELDS OF TABLE“ <--was ist falsch ?
von K0RN » 17.01.2012 16:18 • Verfasst in ABAP® für Anfänger
von K0RN » 17.01.2012 16:18 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
5143
Views
Views
sorted table, hashed table: Übergabe Workarea -> Performa
von Jürgen Fischer » 30.01.2006 08:09 • Verfasst in ABAP® Core
von Jürgen Fischer » 30.01.2006 08:09 • Verfasst in ABAP® Core
5
Antw.
Antw.
9880
Views
Views
1
Antw.
Antw.
2141
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.