Hilfe bei SQL Join


Getting started ... Alles für einen gelungenen Start.

Moderatoren: Jan, Steff

Hilfe bei SQL Join

Beitragvon moo_jo » 16.11.2018, 14:46

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
moo_jo
ForumUser
 
Beiträge: 25
Registriert: 13.10.2017, 08:34
Dank erhalten: 6 mal
Ich bin: Entwickler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: Hilfe bei SQL Join

Beitragvon M@atze! » 21.11.2018, 10:33

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
 
M@atze!
ForumUser
 
Beiträge: 12
Registriert: 19.02.2018, 15:40
Dank erhalten: 2 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon moo_jo » 23.11.2018, 08:43

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
moo_jo
ForumUser
 
Beiträge: 25
Registriert: 13.10.2017, 08:34
Dank erhalten: 6 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon LostDarkness » 26.11.2018, 15:25

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
LostDarkness
ForumUser
 
Beiträge: 11
Registriert: 07.06.2018, 10:21
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon DeathAndPain » 29.11.2018, 17:46

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.
DeathAndPain
Expert
 
Beiträge: 849
Registriert: 05.05.2006, 10:14
Dank erhalten: 197 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon ralf.wenzel » 01.12.2018, 21:38

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

Für diese Nachricht hat ralf.wenzel einen Dank bekommen :
tm987456
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Hilfe bei SQL Join

Beitragvon deejey » 02.12.2018, 08:21

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.
deejey
Specialist
 
Beiträge: 150
Registriert: 31.07.2016, 11:20
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon ralf.wenzel » 02.12.2018, 08:41

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.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Hilfe bei SQL Join

Beitragvon moo_jo » 03.12.2018, 16:29

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.
moo_jo
ForumUser
 
Beiträge: 25
Registriert: 13.10.2017, 08:34
Dank erhalten: 6 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon ralf.wenzel » 03.12.2018, 16:40

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
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Hilfe bei SQL Join

Beitragvon DeathAndPain » 03.12.2018, 17:47

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.

*&amp;---------------------------------------------------------------------*
*&amp;      Form  ZWEI
*&amp;---------------------------------------------------------------------*
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.
DeathAndPain
Expert
 
Beiträge: 849
Registriert: 05.05.2006, 10:14
Dank erhalten: 197 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon a-dead-trousers » 03.12.2018, 18:04

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.07
Basis: 7.40
a-dead-trousers
Top Expert
 
Beiträge: 3107
Registriert: 07.02.2011, 13:40
Dank erhalten: 767 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon ralf.wenzel » 03.12.2018, 18:12

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.
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Hilfe bei SQL Join

Beitragvon DeathAndPain » 03.12.2018, 18:14

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.
DeathAndPain
Expert
 
Beiträge: 849
Registriert: 05.05.2006, 10:14
Dank erhalten: 197 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon ralf.wenzel » 03.12.2018, 18:35

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.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Nächste

Zurück zu ABAP® für Anfänger

  Aktuelle Beiträge   
Umrechnung Stück in KG
vor 2 Stunden von Nordlicht 0 Antw.
gelöst Sel.Screen in Subscreen - VA06
vor 16 Stunden von bapimueller 2 Antw.
gelöst Prüfen Konfiguration Kundenauftrag gene Type
vor 22 Stunden von mfromg 0 Antw.
Auswertung Orders erhalt per Mail oder FAX oder beides
vor 16 Stunden von ewx 2 Antw.
SAP und Gamification
Gestern von ewx 1 Antw.

  Ähnliche Beiträge beta
Hilfe bei SQL Join
16.11.2018, 21:40 von deejey 1 Antw.
Brauche Hilfe zu Update nach Join in ITAB
28.07.2008, 10:33 von laola 4 Antw.
Inner join
19.01.2006, 14:28 von Gast 4 Antw.
JOIN
23.02.2006, 17:15 von robin1at 17 Antw.
inner join
14.05.2007, 15:31 von Krueger 3 Antw.

 

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot], Google Adsense [Bot]