Alphanumerische Werte eingrenzen (ähnlich Between)

[frankyboy1974]

hallo,

@baumina

kannst du mir bitte für diese Aussage ein Beispiel nennen

Zitat:

Dem stimme ich zu, nur ganz selten macht es Sinn Bedingungen in den Join statt in die Where-Clause zu nehmen

Ich sehe ehrlich gesagt gar keinen Unterschied, ob ich an der Stelle mit Where weiter mache, oder denn Join weiterführe. Aber du wirst mir sicherlich ein gutes Beispiel nennen können, beim dem der Unterschied deutlich wird, wann es Sinn macht und wann nicht.

mfg

[baumina]

Beim INNER JOIN ist es egal, für RIGHT und LEFT JOIN gilt LEFT JOIN and RIGHT JOIN Optimization

[p80286]

Zitat von frankyboy1974:

Ich sehe ehrlich gesagt gar keinen Unterschied, ob ich an der Stelle mit Where weiter mache, oder denn Join weiterführe.

Hätte ich bis vor kurzem auch zugestimmt, bis ich einen

Code:

T1 LEFT JOIN T2 ON (T1.ID=T2.ID and T2.Wert=xxx and T2.wert1=yyyy)

hatte, der sich wie ein INNER JOIN verhielt. Ist zwar Oracle aber da sollte es eigentlich auch gehen.

Gruß
K-H

[jobo]

Zitat von frankyboy1974:

@baumina

kannst du mir bitte für diese Aussage ein Beispiel nennen

Zitat:

Dem stimme ich zu, nur ganz selten macht es Sinn Bedingungen in den Join statt in die Where-Clause zu nehmen

Ich bin zwar nicht baumina, aber muss dazu auch meinen Senf loswerden.

Ich bin es von "oracle" sql gewohnt, ohne ANSI Join Syntax zu arbeiten, gefällt mir auch viel besser, ist aber tatsächlich wohl nur Gewohnheit.
Im "Oracle" Style schreibt man alles hinter das "where" und ist glücklich. Technisch kann man auch alles in die ANSI Join Notation reinquetschen, also sozusagen das Gegenteil des "Oracle" Style.
Mal abgesehen von den Vorschriften, die es gibt, die sowieso zur Trennung von join und Bedingung bzw. Filter anhalten.
Man nimmt sich einfach ohne Not die Übersicht(lichkeit) und nicht nur sich, auch den Kollegen.
Über die Join Notation formuliert man die Kriterien zur (korrekten) Mengenbildung, die Filter im Where dienen tatsächlich dann nur noch dazu, das Ergebnis auszusieben.
Das sieht vielleicht nach Erbsenzählerei aus, kann einem bei komplexen Abfragen aber durchaus mal den Kopf retten. Es trägt zum Verständnis der Abfrage bei und ist hilfreich bei der Fehlersuche und vielleicht sogar schon bei der Erstellung.

Etwas plastisch wird das vielleicht bei typischen Programmieraufgaben, wo eine Filtermaske implementiert werden muss. Was auch immer der User möchte, den zusammengesetzten Filterausdruck setzt ganz sorgenfrei in die Where Clause, genau da gehört er hin. Die Joinkriterien des Selectstatements bleiben unangetastet.

[idefix2]

Intuitiv hätte ich gemeint, dass so eine Abfrage effizienter abgearbeitet werden kann, wenn einige Bedingungen, die viele Datensätze ausscheiden, schon im join festgelegt werden, weil dann die Ergebnismenge des joins kleiner ist? Was ist daran falsch?

[Sir Rufo]

Zitat von idefix2:

Intuitiv hätte ich gemeint, dass so eine Abfrage effizienter abgearbeitet werden kann, wenn einige Bedingungen, die viele Datensätze ausscheiden, schon im join festgelegt werden, weil dann die Ergebnismenge des joins kleiner ist? Was ist daran falsch?

Daran ist erst einmal gar nichts falsch.

Ob das aber wirklich effizienter abgearbeitet wird und wenn, bei welcher Datenmenge und welcher Datenstruktur, hängt sehr stark vom DBMS und dem Optimizer ab.

Man kann pauschal da gar nichts sagen, nur ein konkreter Test kann hier die letztendliche Erkenntnis bringen.

Manchmal gibt es auch recht konkrete Aussagen zu einem konkreten DBMS
https://www.percona.com/blog/2010/04...oin-and-where/

Oder sowas http://stackoverflow.com/questions/1...r-than-a-where

(Ich suche noch einen Link zu einer Seite, auf der unterschiedliche Performance-Tests mit einem MS-SQL Server gemacht wurden, und dort gab es teilweise unterschiedliche Laufzeitverhalten abhänging von der Satzanzahl. Der scheint sich im Moment aber gut zu verstecken)

[jobo]

Zitat von Sir Rufo:

(Ich suche noch einen Link zu einer Seite, auf der unterschiedliche Performance-Tests mit einem MS-SQL Server gemacht wurden, und dort gab es teilweise unterschiedliche Laufzeitverhalten abhänging von der Satzanzahl. Der scheint sich im Moment aber gut zu verstecken)

Sag Bescheid, wenn Du ihn gefunden hast

Zitat:

Ob das aber wirklich effizienter abgearbeitet wird und wenn, bei welcher Datenmenge und welcher Datenstruktur, hängt sehr stark vom DBMS und dem Optimizer ab.

Genau! Und an der Stelle erledigt sich eigentlich jede Fragestellung, die nicht exakt an einem System (Hersteller) einer Version (plus Hardware, Cache Größen, Partitionierung etc. pp) entlang läuft .

Ich hab im Rahmen dieses Threads ein paar Sachen auf Oracle ausprobiert. Ein Feld 80 % mit NULL "gefüllt", mit Index, 9 Mio Datensätze. Sucht man nach einem Wert, dessen Häufigkeit deutlich unter 1% ist, wird der Index verwendet, der nächste Wert liegt bei ca 4% Häufigkeit, da wird dann schon Fulltablescan gemacht. Ich bin überrascht.

Das Problem an Threads wie diesen ist, dass immer wieder bestimmte Regeln für richtig erklärt werden, es aber einfach nicht sind, im schlimmsten Fall nicht mal im Besonderen. Thematisch ein Legendenklassiker. Aktuelle Systeme haben sehr pfiffige Optimizer, denen häufig eine Menge Blödsinn und eine Menge KI angedichtet wird.

Deswegen (auch falls ich mich wiederhole)
Prio 1: Fachlich solide Abfrage schreiben und auf den Optimizer vertrauen.
Prio 2: Doku
Prio 3: Tuning, falls nötig, dann aber besonders gut dokumentieren, warum man so komische Abfragen schreibt/ Indizes erstellt/ ..