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 / 134 / 17 / 19 ) »

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


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


Re: Hilfe bei SQL Join

Beitrag von a-dead-trousers (Top Expert / 4399 / 223 / 1182 ) »
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.18
Basis: 7.50

Re: Hilfe bei SQL Join

Beitrag von DeathAndPain (Top Expert / 1952 / 259 / 413 ) »
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 / 4399 / 223 / 1182 ) »
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.18
Basis: 7.50

Re: Hilfe bei SQL Join

Beitrag von ralf.wenzel (Top Expert / 3935 / 200 / 281 ) »
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
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 / 1952 / 259 / 413 ) »
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 / 4099 / 128 / 941 ) »
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 / 4099 / 128 / 941 ) »
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 / 1952 / 259 / 413 ) »
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.

Vergleichbare Themen

1
Antw.
1521
Views
Hilfe bei SQL Join
von moo_jo » 16.11.2018 14:51 • Verfasst in ABAP® für Anfänger
5
Antw.
2127
Views
select join hilfe
von dimes » 07.03.2006 16:56 • Verfasst in ABAP® Core
4
Antw.
2758
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.
1224
Views
Join mit Left Outer Join
von Rude1986 » 17.01.2021 19:53 • Verfasst in ABAP® für Anfänger
6
Antw.
819
Views
Inner Join
von L0w-RiDer » 26.03.2021 14:52 • Verfasst in ABAP® für Anfänger

Aktuelle Forenbeiträge

Daten an Tabelle binden
vor 12 Stunden von Bright4.5 3 / 1485
Regex in where
vor 14 Stunden von tar 6 / 158

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.

Aktuelle Forenbeiträge

Daten an Tabelle binden
vor 12 Stunden von Bright4.5 3 / 1485
Regex in where
vor 14 Stunden von tar 6 / 158

Unbeantwortete Forenbeiträge

aRFC im OO-Kontext
vor 5 Wochen von ralf.wenzel 1 / 3261
Hilfe bei SWEC/SWE2
September 2024 von retsch 1 / 9821