Folgende Benutzer bedankten sich beim Autor nickname8 für den Beitrag:
DeathAndPain
nickname8 hat geschrieben:viele Grüße von Horst Keller:
https://blogs.sap.com/2016/06/11/select ... to-1-rows/
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:Practically there is no difference in performance.
Horst Keller hat geschrieben:The paper is open for discussion.
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:Ralf hat geschrieben:Und wieviele Quellen von der SAP brauchst du noch, damit du mir glaubst? Drei hab ich geliefert.
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: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.
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.Horst Keller hat geschrieben:Practically there is no difference in performance.
Nicht weil das zu katastrophal schlechter Performance führen würde.Horst Keller hat geschrieben:Usage of SINGLE is not appropriate here, because the resulting line is undefined.
Wenn du schon den Testreport hast, könntest du noch versuchen Ralfs Behauptung zu entkräften bzw. zu unterstützen.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.
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.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.
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.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.
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
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.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.