Hallo,

mit der Anzahl der Indices und der Normalisierung bin ich voll bei dir.
Das mit den Konvertierungen, das ist wohl eine elementare Schwäche des Query Optimizers (Pessimizer?). Ich habe definitiv vor kurzem einen Query von der Art
SELECT .... from ..... where Feld = xyzCAST(:Feld)
gesehen, der mit dem Aufruf der Konvertierung einen full tablescan ausgelöst hat, der nach Konvertierung des Feldes im Programm weg war.
Das mit dem Visual Explain, so hart wollte ich das garnicht formulieren, das die anderen Sachen alle noch schlechter sind.

mfg

Dieter


Zitat Zitat von B.Hauser
Falsch!

Eine Typen-Konvertierung erfolgt, sofern erforderlich, im Select-Statement, d.h. gegebenenfalls werden Funktionen eingebunden, die Datentypen umsetzen.
Diese zusätzlichen Aufrufe können dann die Verarbeitung ausbremsen.

Erst danach wird nach dem/den optimalen Zugiffsweg(en) gesucht.

Ein Index kann immer nur über bestehende Datei-Felder angelegt werden. Dabei spielt es keine Rolle, ob es sich um einen permanenten oder temporären Index handelt.

Wird ein temporärer Index angelegt oder ein Table Scan ausgeführt, hat dies u.U. andere Ursachen. Da bleibt oft wirklich nur Versuch und Irrtum.

@mott
Eine unterschiedliche Daten-Konstellationen oder Release-Stände zwischen Test- und Echt-Umgebung können den Query Optimizer zu völlig anderen Entscheidungen kommen lassen.

@Dieter
Visual Explain ist im Moment das Beste was IBM in dieser Beziehung zu bieten hat.

Und ... in einer normalisierten Datenbank wird man ausserdem nur eine kleine Anzahl Indices pro Datei benötigen

Birgitta