Hilfe bei SQL Join

Getting started ... Alles für einen gelungenen Start.
24 Beiträge • Seite 1 von 2 (current) Nächste
24 Beiträge Seite 1 von 2 (current) Nächste

Hilfe bei SQL Join

Beitrag von moo_jo (ForumUser / 36 / 10 / 7 ) »
Hallo zusammen,

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).
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

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Hilfe bei SQL Join

Beitrag von M@atze! (ForumUser / 92 / 6 / 21 ) »
Hi,

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

Re: Hilfe bei SQL Join

Beitrag von moo_jo (ForumUser / 36 / 10 / 7 ) »
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

Re: Hilfe bei SQL Join

Beitrag von LostDarkness (ForumUser / 87 / 15 / 6 ) »
moo_jo hat geschrieben:Hallo zusammen,

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).
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
Reicht für ein einzelnes Ergebnis an dieser Stelle nicht auch einfach ein "SELECT SINGLE..." und eine zugehörige ORDER BY-Anweisung?

Liebe Grüße
Gerrit
“You should name a variable using the same care with which you name a first-born child.”
― Robert C. Martin

Re: Hilfe bei SQL Join

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.

Re: Hilfe bei SQL Join

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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

Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
tm987456

Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Hilfe bei SQL Join

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
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.

Re: Hilfe bei SQL Join

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Hilfe bei SQL Join

Beitrag von moo_jo (ForumUser / 36 / 10 / 7 ) »
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.

Re: Hilfe bei SQL Join

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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.
Öhm, genau das macht doch der SELECT...UP TO 1 ROWS. ENDSELECT.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Hilfe bei SQL Join

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.
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.

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.

Re: Hilfe bei SQL Join

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
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.
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

Re: Hilfe bei SQL Join

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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:
Eine SELECT-Anweisung mit dem Zusatz SINGLE ist bei vollständig spezifizierter Zeile in aller Regel schneller als bei unvollständiger Spezifizierung der Zeile.
Es wird empfohlen, den Zusatz UP TO 1 ROWS zu verwenden, um maximal eine Zeile einer Menge von selektierten zu lesen
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?

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.
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Hilfe bei SQL Join

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Du testest in deinem Programm zweimal den SELECT SINGLE und jedes Mal ist ein (Primär-)Index beteiligt.
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.

Lies nochmal sorgsam, was Ralf geschrieben hat, dann wirst Du sehen, dass ich recht habe.

Re: Hilfe bei SQL Join

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Vergleichbare Themen

1
Antw.
1450
Views
Hilfe bei SQL Join
von moo_jo » 16.11.2018 14:51 • Verfasst in ABAP® für Anfänger
5
Antw.
1940
Views
select join hilfe
von dimes » 07.03.2006 16:56 • Verfasst in ABAP® Core
4
Antw.
2484
Views
Brauche Hilfe zu Update nach Join in ITAB
von laola » 23.07.2008 16:42 • Verfasst in ABAP® für Anfänger
1
Antw.
755
Views
Join mit Left Outer Join
von Rude1986 » 17.01.2021 19:53 • Verfasst in ABAP® für Anfänger
1
Antw.
1335
Views
inner join
von dimes » 20.01.2006 07:57 • Verfasst in ABAP® Core

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 4 Tagen von Lucyalison 1 / 72
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141