Anonym.
Hallo,
wenn in einem SQL der linke Teil einer OR-Verknüpfung TRUE ist, wird dann der rechte Teil noch geprüft? (ORELSE im .NET)
(analog natürlich wenn der linke Teil einer AND-Verknüpfung FALSE ist)
Wenn die rechte (womöglich sehr komplexe) Seite noch geprüft wird, könnte es Sinn machen, einen SQL in 2 zu teilen …
Danke
Alexander
Hi Alex,
Die Unterschiede zwischen OR/ORELSE und AND/ANDALSO sind (in .NET) folgende:
If you use OR, then both Expression1 and Expression2 will be evaluated. If either is True then the Result is True.
However, if you use ORELSE and Expression1 is found to be True then Expression2 is not evaluated.The same applies to AND and ANDALSO, the latter being the short circuit version. If the first test returns True then the second expression is not evaluated.
The AND and the OR logical operators always evaluate BOTH expressions regardless of the value of the first expression. (I’m not entirely sure why, but I do know that this is the case.)
The inclusion of the short circuit versions allow developers to place the expression which runs fastest as Expression1 and if it results in not needing to call Expression2 (which takes longer) then there is a performance increase.
Ich meine, dass es auf jeden Fall Sinn macht [unnütze] I/O zu vermeiden. Typisches Beispiel: ‚Nehme ich nun ein OR-Prädikat oder ist ein UNION besser?‚
Ich würde ein SQL nicht aufsplitten, denn damit sind zahlreiche Aktionen verbunden: Autorisierungsprüfung, Zugriffsplanerstellung, zusätzliche/erneute I/O.
Gruß
Gernot
Hi Gernot,
ich weiss, was die Unterschiede sind 😉 Habe das nur zur Verdeutlichung angeführt. Ich wollte wissen, ob DB2 implizit nach ORELSE-Prinzip arbeitet.
ich vermute/behaupte, DB2 wertet immer beide Expressions aus. Eine IN-Liste kann man ja auch als OR-Verknüpfung auflösen. Und wenns keine Existensprüfung ist, will man ja alle haben.
Anderes Beispiel:
ich habe eine Existenzprüfung (FETCH FIRST 1 ROW ONLY) mit einer ellenlangen IN-Liste in der WHERE-Bedingung. Da wäre es doch klasse, wenn der SQL nach dem ersten IN-Treffer der quasi OR-Verknüpfung diese Prüfung abbricht.
Und wenn man eine Vorstellung über die Datenausprägung hat, macht doch eine Aufsplittung sicher Sinn. Einfache Expression1, die meist schon trifft und aufwendige Expression2, die deshalb meist unnötig ist. Innerhalb eines Programms sollte das kein Problem sein. (Macht natürlich nur Sinn für Existenzprüfungen)
Grüsse
Alexander
Hallo Alexander,
bei einem EXISTS-Prädikat wird die Suche nach dem ersten Treffer beendet.
Wenn Du nicht vorherbestimmen kannst, wie häufig der 1. Block Treffer zeigt und man sich dann den 2. Block eigentlich sparen könnte, wird die Bestimmung einer Ersparnis durch Aufteilung in 2 Blocks schwierig. Denn der 2. Block (quasi das OR-Prädikat) verschlingt ja erneut I/O-Kosten.
Wie gesagt: Wenn man die Ersparnis nicht absehen kann, würde ich das SQL Statement nicht teilen und die Sache dem Optimizer überlassen.
Gruß
Gernot
PS: Bei einer gleichen Trefferwahrscheinlichkeit und gleichen Kosten für beide Blöcke, wobei das OR-Prädikat in einem zusammengesetzten Statement (wg. ersparter I/O) Kosten spart, könnte sich folgendes ergeben: (siehe Bild)
You must be logged in to reply to this topic.
