Hilfe bei SQL Join


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

Moderatoren: Jan, Steff

Re: Hilfe bei SQL Join

Beitragvon nickname8 » 03.12.2018, 20:55


Für diese Nachricht hat nickname8 einen Dank bekommen :
DeathAndPain
nickname8
ForumUser
 
Beiträge: 75
Registriert: 18.07.2015, 08:22
Dank erhalten: 9 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 a-dead-trousers » 03.12.2018, 23:32

nickname8 hat geschrieben:viele Grüße von Horst Keller:
https://blogs.sap.com/2016/06/11/select ... to-1-rows/

Horst Keller hat geschrieben:Practically there is no difference in performance.

Aber er hat nur 4 Anwendungsfälle spezifiziert und bei jedem hat er entweder nur SELECT SINGLE oder nur SELECT UP TO X ROWS verwendet. Nie beides für einen Anwendungsfall. Nur bei der Existenzprüfung lässt er beides zu, wobei er das UP TO X ROWS nur einsetzt um das Pragma zu vermeiden. Also hat jeder der Befehle seine Berechtigung und keiner steht für sich genommen über dem anderen (oder ist besser als der andere). Es kommt somit immer auf den Anwendungfall an, welcher der Befehle besser geeignet ist. In der aktuellen Diskussion welcher der beiden Befehle in der tatsächlichen DB-Syntax (Oracle, Hana, usw.) bessere/schnellere Ergebnisse liefert kommen wir damit IMHO nicht weiter. Man darf ja nicht vergessen, dass zwischen OpenSQL und "echtem" SQL noch eine Abstraktionsschicht liegt.
Horst Keller hat geschrieben:The paper is open for discussion.

:P
Hilft auch nicht wirklich weiter.
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: 3090
Registriert: 07.02.2011, 13:40
Dank erhalten: 762 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon DeathAndPain » 04.12.2018, 09:52

Also mir hat nickname8's Link sehr geholfen, da er eindeutig belegt, dass Ralf sich irrt.

Ralf hat geschrieben:Und wieviele Quellen von der SAP brauchst du noch, damit du mir glaubst? Drei hab ich geliefert.

Wenn Du denkst, dass diese Zitate von Dir Deine Behauptung stützen, dann hast Du sie nicht genau genug gelesen. Aber dank nickname8's Link haben wir jetzt ja den eindeutigen Gegenbeweis:

Horst Keller hat geschrieben:TASK: You want to check the existence of a row

You use SINGLE:


SELECT SINGLE col

FROM dbtab

WHERE any_key

INTO (field)

##warn_ok.

IF sy-subrc = 0.



ENDIF.


Horst Keller sagt also ganz klar, dass man hier SELECT SINGLE in Verbindung mit einem beliebigen Tabellenschlüssel verwenden kann. Das würde er ganz sicher nicht tun, wenn das im Falle eines Nichtprimärschlüssels zu einer sequentiellen Suche über die Datenbank führen würde. Im Übrigen konstatiert er am Ende ja auch ausdrücklich:

Horst Keller hat geschrieben:Practically there is no difference in performance.


Wie gesagt, man kann sich das auch selber daraus herleiten, dass der Suchschlüssel ja stets von der Datenbank gewählt wird (die sogar auf einem anderen Server beheimatet sein kann) und nicht vom ABAP.

Bei einem nur teilweise bestimmten Schlüssel ("partly specified key") empfiehlt Horst Keller den UP TO 1 ROWS, weil er dazu rät, dann stets ORDER BY anzugeben, um keine zufällige Ergebniszeile zu erhalten. Implizit vertritt er dabei die Auffassung, dass abgesehen von reinen Existenzprüfungen zufällige Ergebniszeilen niemals wünschenswert sind. Ich teile seine Meinung nicht, verstehe aber, wie er dazu kommt.

Horst Keller hat geschrieben:Usage of SINGLE is not appropriate here, because the resulting line is undefined.

Nicht weil das zu katastrophal schlechter Performance führen würde.

Also, manchmal lohnt es sich, den eigenen Kopf zu benutzen, anstatt irgendwelche missverständlichen Sätze vom Hersteller fehlzuinterpretieren. Deine Behauptung war so absurd, dass ich sofort mit sicherer Stimme gesagt habe, kann nicht angehen, aber weil ich Dein Wissen ernst nehme, habe ich meinen anderslautenden Standpunkt dann noch mit dem Testreport abgesichert. Mittlerweile haben wir ja auch die Bestätigung von Horst Keller vorzuliegen.

Vielleicht denkst Du mal darüber nach, ob es sinnvoll ist, solche Auffassungen mit solcher Selbstüberzeugung zu behaupten, dass, wenn ein anderer sich die Mühe macht, aufwendig einen Testreport dafür zu schreiben, um Deine Aussage zu untersuchen, Du Dir noch nicht mal die Mühe machst, einen Blick darauf zu werfen. Finde ich schon eine ziemlich überhebliche Geisteshaltung.
DeathAndPain
Expert
 
Beiträge: 814
Registriert: 05.05.2006, 10:14
Dank erhalten: 189 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon a-dead-trousers » 04.12.2018, 10:47

DeathAndPain hat geschrieben:Vielleicht denkst Du mal darüber nach, ob es sinnvoll ist, solche Auffassungen mit solcher Selbstüberzeugung zu behaupten, dass, wenn ein anderer sich die Mühe macht, aufwendig einen Testreport dafür zu schreiben, um Deine Aussage zu untersuchen, Du Dir noch nicht mal die Mühe machst, einen Blick darauf zu werfen. Finde ich schon eine ziemlich überhebliche Geisteshaltung.

Wenn du schon den Testreport hast, könntest du noch versuchen Ralfs Behauptung zu entkräften bzw. zu unterstützen.
Du müsstest nur den gleichen Zugriff auf die Tabelle machen, einmal mit SINGLE und das andere mal mit UP TO 1 ROWS, wobei du KEINEN vorhandenen Index nutzt.
So wie ich Ralfs Behauptung interpretiert habe, müsste der UP TO 1 ROWS schneller sein. Als Gegencheck kannst du auch testen ob die beiden Befehle MIT einem Index unterschiedlich schnell arbeiten.

Warum kann ich das nicht selber machen?
Weil dann das Testergebnis verfälscht wird, da es sehr stark von der benutzten Datenbank abhängt.
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: 3090
Registriert: 07.02.2011, 13:40
Dank erhalten: 762 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon ralf.wenzel » 04.12.2018, 10:51

Ich hab parallel das gemacht, was ich immer mache, wenn ich vor einer solchen Situation stehe: Ich bin in die nächste Kirche und habe zu Go.... -- nee, ich bin ins SCN und habe eine Mail an Horst Keller geschickt ;)

Das ist das Einfachste, um diesen vermeintlichen Widerspruch aufzulösen.



Ralf
ralf.wenzel
Top Expert
 
Beiträge: 3242
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 190 mal
Ich bin: Freiberufler/in

Re: Hilfe bei SQL Join

Beitragvon DeathAndPain » 04.12.2018, 11:14

adt hat geschrieben:Wenn du schon den Testreport hast, könntest du noch versuchen Ralfs Behauptung zu entkräften bzw. zu unterstützen.
Du müsstest nur den gleichen Zugriff auf die Tabelle machen, einmal mit SINGLE und das andere mal mit UP TO 1 ROWS, wobei du KEINEN vorhandenen Index nutzt.
So wie ich Ralfs Behauptung interpretiert habe, müsste der UP TO 1 ROWS schneller sein.

Nein. Wenn ich keinen Index habe, dann hat die Datenbank ja gar keine andere Wahl, als sequentiell zu suchen. Da ist ja gar nichts anderes möglich. Da werden beide Ansätze daher gleichermaßen schlecht performen.

Ralf hatte behauptet, dass der UP TO 1 ROWS auch weitere Datenbankindizes nutzen kann (was stimmt), der SELECT SINGLE jedoch nicht (was nicht stimmt, woran Horst Keller ja in seinem oben zitierten Text keinen Zweifel gelassen hat).
DeathAndPain
Expert
 
Beiträge: 814
Registriert: 05.05.2006, 10:14
Dank erhalten: 189 mal
Ich bin: Entwickler/in

Re: Hilfe bei SQL Join

Beitragvon black_adept » 04.12.2018, 13:22

DeathAndPain hat geschrieben:Bei einem nur teilweise bestimmten Schlüssel ("partly specified key") empfiehlt Horst Keller den UP TO 1 ROWS, weil er dazu rät, dann stets ORDER BY anzugeben, um keine zufällige Ergebniszeile zu erhalten. Implizit vertritt er dabei die Auffassung, dass abgesehen von reinen Existenzprüfungen zufällige Ergebniszeilen niemals wünschenswert sind. Ich teile seine Meinung nicht, verstehe aber, wie er dazu kommt.
Den selben Gedankengang hatte ich beim Lesen des Hinweises immer ein "ORDER BY" zu verwenden auch. Aber wenn man ein nicht eindeutiges Ergebnis verkraften kann frage ich mich, ob ein "UP TO 1 ROW" und ein "UP TO 1 ROW ... ORDER BY" gleich schnell sind, da ja im von H.K. präferierten Fall die DB zunächst alle Datensätze selektieren und dann noch sortieren muss um den 1. davon zurück zu liefern, wohingegen ohne ein ORDER BY die Sortierung entfallen kann und eine schlaue Datenbank bei UP TO 1 ROW ohne ORDER BY nicht mal alle Sätze holen müsste.
Ich würde die Frage ja auch direkt in dem Thread schreiben - aber nicht nachdem der schon 2 Jahre alt ist und wahrscheinlich sowieso keiner mehr drüber schaut.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 3101
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 526 mal
Ich bin: Freiberufler/in

Re: Hilfe bei SQL Join

Beitragvon black_adept » 04.12.2018, 13:28

Und noch ein Zitat von H.K. weiter unten aus den Forenbeiträgen:
Horst Keller hat geschrieben:What I’m wondering about …
Of course one should always use the best method possible, but is the performance of an existence check really that important?
Isn’t the performance of a mass access much more important?
So, if you have mass existence checks, Ok, but otherwise, hmm.
What do you think?
PS: If you wonder why I say this after writing such a blog: the blog is more about semantics, less about performance, assuming that the performance of the shown alternatives isn’t too different.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Für diese Nachricht hat black_adept einen Dank bekommen :
a-dead-trousers
black_adept
Top Expert
 
Beiträge: 3101
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 526 mal
Ich bin: Freiberufler/in

Re: Hilfe bei SQL Join

Beitragvon DeathAndPain » 04.12.2018, 15:12

black_adept hat geschrieben:Den selben Gedankengang hatte ich beim Lesen des Hinweises immer ein "ORDER BY" zu verwenden auch. Aber wenn man ein nicht eindeutiges Ergebnis verkraften kann frage ich mich, ob ein "UP TO 1 ROW" und ein "UP TO 1 ROW ... ORDER BY" gleich schnell sind, da ja im von H.K. präferierten Fall die DB zunächst alle Datensätze selektieren und dann noch sortieren muss um den 1. davon zurück zu liefern, wohingegen ohne ein ORDER BY die Sortierung entfallen kann und eine schlaue Datenbank bei UP TO 1 ROW ohne ORDER BY nicht mal alle Sätze holen müsste.

Deine Einschätzung ist mit Sicherheit richtig, widerspricht aber nicht dem, was Horst Keller ausgedrückt hat. Er steht nämlich auf dem Standpunkt, dass jenseits reiner Existenzchecks nicht eindeutige Ergebnisse niemals als "verkraftbar" (wie Du es ausdrückst) einzuschätzen sind, so dass sich die Frage, ob man in dem Fall ohne ORDER BY besser dasteht, gar nicht erst stellt. Genau das ist der Punkt, den ich meinte, als ich sagte, dass ich seine Meinung nicht teile. Er vertritt hier einen sehr akademischen Standpunkt: Wenn ich genau eine einzige Zeile lesen möchte, dann muss ich auch genau angeben (können), welche ich haben will, sonst wird das Verhalten meines Programms undefinierbar. Aus diesem akademischen Blickwinkel kann ich seinen Standpunkt nachvollziehen, finde ihn aber praxisfern, da man das in der Realität durchaus in vielen Fällen "verkraften" kann. Und anscheinend sind wir uns da mit dieser Einschätzung einig, jedenfalls was diejenigen angeht, die sich hier bisher zu diesem Aspekt geäußert haben.
DeathAndPain
Expert
 
Beiträge: 814
Registriert: 05.05.2006, 10:14
Dank erhalten: 189 mal
Ich bin: Entwickler/in

Vorherige

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

  Aktuelle Beiträge   
s4hana-cloud
vor 8 Stunden von sap_inchen 1 Antw.
500 Internal Server Error
vor 16 Stunden von zzcpak 1 Antw.
Dokumentinformationen lesen vom DVS
vor 18 Stunden von Tron 4 Antw.
Tabs innerhalb von Tabs
vor 19 Stunden von ewx 4 Antw.
Fakturierungsplan in Kontrakten ändern
vor 15 Stunden von DeathAndPain 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]