Hilfe bei SQL Join
Hallo zusammen,
Kann mir bitte jemand einen Tipp für den SQL Join geben.
In diesem vereinfachten Beispiel habe ich das Problem, dass der SELECT mir alle MeasurementDocuments zu dem MeasurementPoint zurückgibt. Ich möchte aber nur das aktuelle / neueste Measurement Document.
Jetzt hätte ich gehofft den JOIN noch einzugrenzen, aber da stehe ich gerade auf dem Schlauch?
Problem verstanden?
Dankeeeee!
Moo_jo
Kann mir bitte jemand einen Tipp für den SQL Join geben.
Code: Alles auswählen.
Select imrg~mdocm,
imrg~point,
imrg~mdocm,
imrg~recdv,
imptt~psort,
imptt~pttxt,
imptt~decim
FROM imrg
JOIN imptt on imptt~point = imrg~point
where imrg~woobl = @iv_objnr
into table @data(lt_result).
Jetzt hätte ich gehofft den JOIN noch einzugrenzen, aber da stehe ich gerade auf dem Schlauch?
Problem verstanden?
Dankeeeee!
Moo_jo
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hi,
also wenn du es unbedingt mit in den Select packen willst/musst könnte es so aussehen:
Ich halte sowas ja für
1. nicht schön
2. unperformant
Ich würde ins Ergebnis des Selects die Felder ERDAT und ERUHR aufnehmen und dann:
also wenn du es unbedingt mit in den Select packen willst/musst könnte es so aussehen:
Code: Alles auswählen.
SELECT imrg~mdocm,
imrg~point,
imrg~recdv,
imptt~psort,
imptt~pttxt,
imptt~decim
FROM imrg
JOIN imptt ON imptt~point = imrg~point
WHERE imrg~woobj = @iv_objnr
AND imrg~erdat = ( SELECT MAX( erdat )
FROM imrg
WHERE woobj = @iv_objnr )
AND imrg~eruhr = ( SELECT MAX( eruhr )
FROM imrg
WHERE woobj = @iv_objnr
AND erdat = ( SELECT MAX( erdat )
FROM imrg
WHERE woobj = @iv_objnr ) )
INTO TABLE @DATA(lt_result).
Ich halte sowas ja für
1. nicht schön
2. unperformant
Ich würde ins Ergebnis des Selects die Felder ERDAT und ERUHR aufnehmen und dann:
Code: Alles auswählen.
SORT lt_result DESCENDING BY erdat eruhr.
DATA(ls_result) = lt_result[ 1 ]. " " #91; sowie #93; stehen für eckige Klammern
Danke dir!
Ich bin da etwas zwiegespalten. Heißt es nicht, dass man HANA Optimiert Programmiert und möglichst viel Logik auf der Datenbank ausführt? (Code Pushdown)
Allerdings mit dem negativen Seiteneffekt das SQL Select komplizierter werden und a) nicht jeder Entwickler sich in den Select reindenkt und b) Bugfixing bei einem Select sehr schwierig werden kann?
In meinem Beispiel ist das noch im grünen Bereich meiner Meinung nach. Aber was ist mit einem Selct mit inner/outer Join über mehrere Tabellen mit Subselects und Group By Funktionen...
?
Lg
Moo_jo
Ich bin da etwas zwiegespalten. Heißt es nicht, dass man HANA Optimiert Programmiert und möglichst viel Logik auf der Datenbank ausführt? (Code Pushdown)
Allerdings mit dem negativen Seiteneffekt das SQL Select komplizierter werden und a) nicht jeder Entwickler sich in den Select reindenkt und b) Bugfixing bei einem Select sehr schwierig werden kann?
In meinem Beispiel ist das noch im grünen Bereich meiner Meinung nach. Aber was ist mit einem Selct mit inner/outer Join über mehrere Tabellen mit Subselects und Group By Funktionen...
?
Lg
Moo_jo
Beitrag
von LostDarkness (ForumUser / 87 / 15 /
6
)
»
Reicht für ein einzelnes Ergebnis an dieser Stelle nicht auch einfach ein "SELECT SINGLE..." und eine zugehörige ORDER BY-Anweisung?moo_jo hat geschrieben:Hallo zusammen,
Kann mir bitte jemand einen Tipp für den SQL Join geben.In diesem vereinfachten Beispiel habe ich das Problem, dass der SELECT mir alle MeasurementDocuments zu dem MeasurementPoint zurückgibt. Ich möchte aber nur das aktuelle / neueste Measurement Document.Code: Alles auswählen.
Select imrg~mdocm, imrg~point, imrg~mdocm, imrg~recdv, imptt~psort, imptt~pttxt, imptt~decim FROM imrg JOIN imptt on imptt~point = imrg~point where imrg~woobl = @iv_objnr into table @data(lt_result).
Jetzt hätte ich gehofft den JOIN noch einzugrenzen, aber da stehe ich gerade auf dem Schlauch?
Problem verstanden?
Dankeeeee!
Moo_jo
Liebe Grüße
Gerrit
“You should name a variable using the same care with which you name a first-born child.”
― Robert C. Martin
― Robert C. Martin
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
ORDER BY funktioniert aus offensichtlichen Gründen nicht mit SELECT SINGLE (weil es bei SINGLE nichts zu sortieren gibt). Daher wird das schon von der Syntaxprüfung abgelehnt.
Die Idee dahinter ist aber gut und das, woran ich bei der Frage auch gedacht habe. Man kann die Syntaxprüfung austricksen, indem man statt SINGLE einfach UP TO 1 ROWS schreibt (an der syntaktisch dafür vorgesehenen Stelle, also nicht da, wo der SINGLE steht). Dann geht auch ORDER BY. Allerdings muss man dann natürlich auch ENDSELECT unten drunterschreiben, obgleich man genau weiß, dass diese "Schleife" maximal einmal durchlaufen wird.
Die Idee dahinter ist aber gut und das, woran ich bei der Frage auch gedacht habe. Man kann die Syntaxprüfung austricksen, indem man statt SINGLE einfach UP TO 1 ROWS schreibt (an der syntaktisch dafür vorgesehenen Stelle, also nicht da, wo der SINGLE steht). Dann geht auch ORDER BY. Allerdings muss man dann natürlich auch ENDSELECT unten drunterschreiben, obgleich man genau weiß, dass diese "Schleife" maximal einmal durchlaufen wird.
Beitrag
von ralf.wenzel (Top Expert / 3921 / 200 /
280
)
»
Da viel den Unterschied nicht kennen: SELECT SINGLE ist eine Anweisung, die dazu gedacht ist, mit vollem Primärschlüssel zu lesen. Es greift sich den ersten passenden Satz und bricht dann ab, was z. B. ein ORDER BY schlicht unmöglich macht. Ein SELECT SINGLE mit anderen WHERE Kriterien als dem Primärschlüssel kann unter Umständen eine sequentielle Suche zur Folge haben, die entsprechend lange dauert.
SELECT....UP TO 1 ROWS. ENDSELECT. selektiert alle Sätze, auf die die Bedingung passt und verwendet automatisch den am besten passenden Schlüssel, weil die Anweisung davon ausgeht, dass ihr nicht der volle Primärschlüssel mitgegeben wird. Nach der Selektiom führt sie die Aggregationsanweisungen aus (darum geht der ORDER BY) und gibt einen Satz zurück.
Also: Selektieren mit vollem Primärschlüssel per SELECT SINGLE, in allen anderen Fällen nehme man SELECT....UP TO 1 ROWS.
Ralf
SELECT....UP TO 1 ROWS. ENDSELECT. selektiert alle Sätze, auf die die Bedingung passt und verwendet automatisch den am besten passenden Schlüssel, weil die Anweisung davon ausgeht, dass ihr nicht der volle Primärschlüssel mitgegeben wird. Nach der Selektiom führt sie die Aggregationsanweisungen aus (darum geht der ORDER BY) und gibt einen Satz zurück.
Also: Selektieren mit vollem Primärschlüssel per SELECT SINGLE, in allen anderen Fällen nehme man SELECT....UP TO 1 ROWS.
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
tm987456
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Wobei ich denke, dass das mit dem am besten passenden Schlüssel unsicher ist: wenn eine bestimmte Reihenfolge erwartet wird dann muss man auch order by entsprechend setzen sonst ist ungewiss welchen Satz man mit up to 1 rows zu fassen bekommt, es kann jeder beliebige sein der zu WHERE passt.
Beitrag
von ralf.wenzel (Top Expert / 3921 / 200 /
280
)
»
Es geht nicht um Sicherheit beim besten passenden Schlüssel, sondern (ich wiederhole mich) um die Kosten des DB-Zugriffs. Ein falscher Schlüssel kann da fatale Folgen haben. Und „nimm den erstbesten“ muss nicht zwingend falsch sein — wenn fachlich gesichert ist, dass in der gesuchten Spalte für die Lösungsmenge alle Werte gleich sind. Oder wenn ich nur die Existenz prüfen will (SELECT COUNT ist manchmal erschreckend langsam).
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Ein Select Single oder up to 1 rows würde mir nicht helfen.
In der IMRG Tabelle lese ich circa 50 Messpunkte aus. Wenn ein Mitarbeiter einen Messpunkt aktualisiert oder modifziert wird ein neuer Eintrag erstellt.
Ich möchte also jeden Messpunkt genau 1 mal auslesen, wenn er öfters in der Tabelle vorkommt, dann den neuesten. Und das am liebsten in einem SQL Select.
In der IMRG Tabelle lese ich circa 50 Messpunkte aus. Wenn ein Mitarbeiter einen Messpunkt aktualisiert oder modifziert wird ein neuer Eintrag erstellt.
Ich möchte also jeden Messpunkt genau 1 mal auslesen, wenn er öfters in der Tabelle vorkommt, dann den neuesten. Und das am liebsten in einem SQL Select.
Beitrag
von ralf.wenzel (Top Expert / 3921 / 200 /
280
)
»
Öhm, genau das macht doch der SELECT...UP TO 1 ROWS. ENDSELECT.moo_jo hat geschrieben:Ich möchte also jeden Messpunkt genau 1 mal auslesen, wenn er öfters in der Tabelle vorkommt, dann den neuesten. Und das am liebsten in einem SQL Select.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Also die Behauptung halte ich für so absurd, dass ich sie sofort mit einem Testprogramm nachgeprüft und widerlegt habe. Zu diesem Zweck habe ich meine Lieblingstabelle HRP1001 genutzt, die selbst in unserem Entwicklungssystem über 118.000 Einträge hat. Dort habe ich zwei unterschiedliche Einträge (um datenbankseitiges Caching zu vermeiden) per SELECT SINGLE gesucht, zum einen mit dem Primärschlüssel (na ja, einem so langen Teil davon, dass die Suche eindeutig war), zum anderen mit meinen Lieblingsindex 003. Dazu muss man sagen, dass beide Indizes geeignet sind, Tabellenzeilen zu finden. Der wesentliche Vorteil meines Lieblingsindexs besteht nur darin, dass fachliches Wissen über die Tabelle genutzt wird, um mit Angabe von weniger Spalten gleichfalls die gesuchte Zeile treffend zu beschreiben, was in einer kürzeren WHERE-Bedingung resultiert. Zudem kann man mutmaßen, dass es auch datenbankseitig ein kleines bisschen mehr Performance bringt, wenn er weniger Spalten vergleichen muss.Ralf hat geschrieben:Ein SELECT SINGLE mit anderen WHERE Kriterien als dem Primärschlüssel kann unter Umständen eine sequentielle Suche zur Folge haben, die entsprechend lange dauert.
...
Es geht nicht um Sicherheit beim besten passenden Schlüssel, sondern (ich wiederhole mich) um die Kosten des DB-Zugriffs. Ein falscher Schlüssel kann da fatale Folgen haben.
Die mittels GET RUN TIME FIELD gemessene Laufzeit hätte dennoch vernichtend zugunsten des Primärschlüssels ausgehen müssen, wenn er bei Angabe meines Lieblingsindexes diesen nicht genutzt hätte und stattdessen sequentiell durch die Tabelle gerannt wäre. Tatsächlich kam ich aber bei sechs Messungen pro Ansatz zu folgenden Messwerten (die jeweils erste der beiden Zahlen ist die Messung bei meinem Lieblingsindex, die zweite beim Primärschlüssel):
7.245
11.129
429
223
350
266
339
233
2.606
3.052
433
227
Die starken Schwankungen werden sicherlich systemlastbedingt sein; die dreistelligen Ergebnisse sind darauf zurückzuführen, dass die Datenbank die Ergebnisse meiner SELECTs noch in ihrem Cache hatte, da ich das Programm ja mehrmals kurz hintereinander ausgeführt habe. Interessant ist damit vor allem der erste Messwert, also der ohne Cache, bei dem mein Lieblingsindex vorne liegt. Zwischendurch gibt es auch nochmal ein vierstelliges Ergebnis, bei dem die Datenbank möglicherweise ihren Cache wieder geleert hatte; auch hier hat mein Lieblingsindex gewonnen.
Gewiss sind die Schwankungen bei solchen Messungen ganz erheblich, aber ich behaupte, wenn er bei meinem Lieblingsindex komplett ohne Index gesucht hätte, dann wäre das anders ausgegangen.
Es ist ja auch logisch: Wie will SAP denn verhindern, dass die Datenbank einen passenden Index wählt? Dazu müsste SAP schon einen datenbankspezifischen (!) Datenbank-Hint mitgeben. Das ist unrealistisch anzunehmen, dass die SAP da sowas reingepfuscht hat. Ansonsten macht ABAP ja nichts anderes, als den OpenSQL-Befehl in NativeSQL zu übersetzen und an die Datenbank weiterzureichen. Den Index wählt dann der Optimizer der Datenbank; damit haben weder ABAP noch das SAP-System irgendwas zu tun. Das ist immer so.
Von daher muss ich Dir leider sagen, lieber Ralf, dass Deine Behauptung nicht zu halten ist. Solltest Du dennoch daran festhalten wollen, dann würde ich um handfeste Beweise bitten.
Der Vollständigkeit halber hier mein Testprogramm zur Ansicht. Ich habe die ersten drei Wertpaare mit ERSTEINS und die letzten drei mit ERSTZWEI laufen lassen, um etwaige Auswirkungen der Ausführungsreihenfolge auf die Laufzeit auszugleichen bzw. erkennbar zu machen.
Code: Alles auswählen.
*&---------------------------------------------------------------------*
*& Report ZTEST6
*&---------------------------------------------------------------------*
REPORT ZTEST6.
TABLES HRP1001.
DATA: T1 TYPE I, T2 TYPE I, T3 TYPE I.
PARAMETERS ERSTEINS RADIOBUTTON GROUP ONE.
PARAMETERS ERSTZWEI RADIOBUTTON GROUP ONE.
*** START-OF-SELECTION ***
START-OF-SELECTION.
CASE ERSTEINS.
WHEN 'X'. PERFORM EINS.
PERFORM ZWEI.
WHEN SPACE. PERFORM ZWEI.
PERFORM EINS.
ENDCASE.
*&---------------------------------------------------------------------*
*& Form EINS
*&---------------------------------------------------------------------*
FORM EINS.
GET RUN TIME FIELD T1.
SELECT SINGLE * FROM HRP1001
WHERE SOBID = '50059823'
AND SCLAS = 'S'
AND SUBTY = 'B008'
AND PLVAR = '01'
AND ENDDA = '99991231'
AND BEGDA <= SY-DATUM.
GET RUN TIME FIELD T2.
T3 = T2 - T1.
WRITE / T3.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form ZWEI
*&---------------------------------------------------------------------*
FORM ZWEI.
GET RUN TIME FIELD T1.
SELECT SINGLE * FROM HRP1001
WHERE OTYPE = 'S'
AND OBJID = '50059823'
AND PLVAR = '01'
AND RSIGN = 'A'
AND RELAT = '008'
AND ISTAT = '1'
AND PRIOX = SPACE
AND BEGDA <= SY-DATUM
AND ENDDA = '99991231'.
GET RUN TIME FIELD T2.
T3 = T2 - T1.
WRITE / T3.
ENDFORM.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Du testest in deinem Programm zweimal den SELECT SINGLE und jedes Mal ist ein (Primär-)Index beteiligt.
Ralf meinte das Verhalten eines SELECT SINGLE im Vergleich zu einem SELECT UP TO X ROWS ENDSELECT wenn es eventuell KEINEN Zugriff über einen Index gibt.
Ralf meinte das Verhalten eines SELECT SINGLE im Vergleich zu einem SELECT UP TO X ROWS ENDSELECT wenn es eventuell KEINEN Zugriff über einen Index gibt.
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 ralf.wenzel (Top Expert / 3921 / 200 /
280
)
»
Hm, vielleicht kannst du mir nachsehen, wenn ich erstmal glaube, was die SAP so über ihre eigene Programmiersprache behauptet.
SELECT SINGLE vs. UP TO 1 ROWS:
Nachtrag: ABAP-Referenz, Seite 863 (akt. Ausgabe):
Ralf
SELECT SINGLE vs. UP TO 1 ROWS:
Eine SELECT-Anweisung mit dem Zusatz SINGLE ist bei vollständig spezifizierter Zeile in aller Regel schneller als bei unvollständiger Spezifizierung der Zeile.
Was, glaubst du, tut eine DB, wenn du in der WHERE-Bedingung irgendein Nicht-Schlüsselfeld mitgibst (und kein Schlüsselfeld)? Sie wird nichts anderes tun können, als die DB zu durchsuchen, und zwar sequentiell. Ich kenne die Tabelle nicht, mit der du gearbeitet hast und ich habe jetzt keine Zeit, das nachzuvollziehen (ich packe gleich für eine Geschäftsreise), aber diese Logik sollte sich dir doch erschließen, oder?Es wird empfohlen, den Zusatz UP TO 1 ROWS zu verwenden, um maximal eine Zeile einer Menge von selektierten zu lesen
Nachtrag: ABAP-Referenz, Seite 863 (akt. Ausgabe):
Bei der Angabe von SINGLE sollte die zu lesende Zeile aus Effizienzgründen eindeutig in der WHERE-Bedingung spezifiziert sein. Beim Lesen aus einer Datenbanktabelle geschieht dies durch die Angabe von Vergleichswerten für den Primärschlüssel.
Ralf
Zuletzt geändert von ralf.wenzel am 03.12.2018 18:33, insgesamt 1-mal geändert.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Nein. Es ist jedesmal ein Index beteiligt, aber in einem der beiden Fälle ist es eben nicht der Primärindex. Und genau das ist es, was Ralf hier vehement betont: dass SELECT SINGLE ausschließlich den Primärindex nutzen würde und es daher ein fataler Fehler sei, einen SELECT SINGLE zu nutzen, wenn man einen anderen Index als den Primärschlüssel angibt.Du testest in deinem Programm zweimal den SELECT SINGLE und jedes Mal ist ein (Primär-)Index beteiligt.
Lies nochmal sorgsam, was Ralf geschrieben hat, dann wirst Du sehen, dass ich recht habe.
Beitrag
von ralf.wenzel (Top Expert / 3921 / 200 /
280
)
»
Und wieviele Quellen von der SAP brauchst du noch, damit du mir glaubst? Drei hab ich geliefert. Ich habe übrigens geschrieben KANN (gemeint war: Unter ungünstigen Bedingungen) eine sequentielle Suche in der Tabelle zur Folge haben. Ich habe, wie gesagt, keine Zeit, deinen Test zu analysieren, aber im Zweifel reicht mir, was der Hersteller sagt, ehe ich mir anmaße, es besser zu wissen als er.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Vergleichbare Themen
1
Antw.
Antw.
1517
Views
Views
4
Antw.
Antw.
2748
Views
Views
Brauche Hilfe zu Update nach Join in ITAB
von laola » 23.07.2008 16:42 • Verfasst in ABAP® für Anfänger
von laola » 23.07.2008 16:42 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
1218
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 8 Stunden von DeathAndPain 4 / 664
vor 8 Stunden von DeathAndPain 4 / 664
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 8 Stunden von DeathAndPain 4 / 664
vor 8 Stunden von DeathAndPain 4 / 664