subselect ohne Ergebnis

[Armin]

Das war´s.
Und sooooo einfach.

Die ganze Literatur ersetzt nicht die Möglichkeit eine Frage zu stellen.

Eine hab ich noch!
Soll generell DISTINCT bei subselects für die IN-Klausel verwendet werden?

[BenderD]

Hallo,

frei nach Theorie ist das Banane, weil SQL nach dem Kohl Prinzip arbeitet, aber ein Index für den Subselect sollte ohnehin da sein und dann kanns eher nutzen als schaden.

mfg

Dieter Bender

Das war´s.
Und sooooo einfach.

Die ganze Literatur ersetzt nicht die Möglichkeit eine Frage zu stellen.

Eine hab ich noch!
Soll generell DISTINCT bei subselects für die IN-Klausel verwendet werden?

[Fuerchau]

DISTINCT zwingt immer dazu ALLE Sätze zu verarbeiten und dann doppelte rauszuschmeissen.
Ohne DISTINCT entfällt das entfernen.
Aber wer weiß, vielleicht merkt der Optimzer das sogar, weil für die IN-Prüfung ist das Zwischenergebnis egal.

Was hier ggf. beschleunigen kann ist eher EXISTS, da hier bereits 1 Vorkommen ausreicht und nicht alle Sätze benötigt werden.

Aber insofern hat Dieter (wie immer) Recht, dass Zugriffspfade wesentlich bedeutender sind.

Insbesonders bei mandantenfähiger Software wird der Mandant gerne vergessen, da man ja nur einen hat

[BenderD]

Hallo,

manchmal lässt sich der exists oder where in durch einen join ersetzen und dann bleibt dem Optimizer fast kein Spielraum mehr Quatsch zu machen (selbst bei der ach so fantastischen neuen Query engine)

mfg

Dieter Bender

DISTINCT zwingt immer dazu ALLE Sätze zu verarbeiten und dann doppelte rauszuschmeissen.
Ohne DISTINCT entfällt das entfernen.
Aber wer weiß, vielleicht merkt der Optimzer das sogar, weil für die IN-Prüfung ist das Zwischenergebnis egal.

Was hier ggf. beschleunigen kann ist eher EXISTS, da hier bereits 1 Vorkommen ausreicht und nicht alle Sätze benötigt werden.

Aber insofern hat Dieter (wie immer) Recht, dass Zugriffspfade wesentlich bedeutender sind.

Insbesonders bei mandantenfähiger Software wird der Mandant gerne vergessen, da man ja nur einen hat