Hilfe bei SQL Join

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

Re: Hilfe bei SQL Join

Beitrag von nickname8 (Specialist / 106 / 15 / 16 ) » 3. Dez 2018 20:55

Folgende Benutzer bedankten sich beim Autor nickname8 für den Beitrag:
DeathAndPain



Re: Hilfe bei SQL Join

Beitrag von a-dead-trousers (Top Expert / 3233 / 81 / 813 ) » 3. Dez 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

Re: Hilfe bei SQL Join

Beitrag von DeathAndPain (Top Expert / 1064 / 123 / 232 ) » 4. Dez 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.

Re: Hilfe bei SQL Join

Beitrag von a-dead-trousers (Top Expert / 3233 / 81 / 813 ) » 4. Dez 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

Re: Hilfe bei SQL Join

Beitrag von ralf.wenzel (Top Expert / 3418 / 150 / 220 ) » 4. Dez 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

Re: Hilfe bei SQL Join

Beitrag von DeathAndPain (Top Expert / 1064 / 123 / 232 ) » 4. Dez 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).

Re: Hilfe bei SQL Join

Beitrag von black_adept (Top Expert / 3254 / 54 / 573 ) » 4. Dez 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

Re: Hilfe bei SQL Join

Beitrag von black_adept (Top Expert / 3254 / 54 / 573 ) » 4. Dez 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.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
a-dead-trousers

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Hilfe bei SQL Join

Beitrag von DeathAndPain (Top Expert / 1064 / 123 / 232 ) » 4. Dez 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.

Vorherige Seite 2 von 2 (current)

Aktuelle Forenbeiträge

Datenquelle einer Query ändern
vor 20 Stunden von Level83 3 / 64
Spaltennummer-Umwandlung Excel.
Gestern von il.ost 7 / 167
Black out im Bereich Objekterzeugung bei Vererbung gelöst
Gestern von Thomas R. 4 / 101

Unbeantwortete Forenbeiträge

Transaktion VL06 Verteilung ausgehender Lieferungen
vor 2 Tagen von SAP_ENTWICKLER 1 / 53
FuBa EXIT_SAPLVEDC_003 S/4 1809
vor 4 Tagen von SAP_ENTWICKLER 1 / 87
CDS VIEW mit BOPF Framework update
vor einer Woche von Abapanfänger 1 / 83
SAP Document Builder: Dokumenterzeugung
vor einer Woche von robin.heidrich 1 / 201
Lohnsteuerbescheinigung
vor einer Woche von kaim77 1 / 120