Tabelle optimieren???

[shmia]

Also Indexe auf Bit-Feldern sind relativ witzlos, weil ein Index darauf im Schnitt nur 50% ausfiltern kann. (aber ich sehe gerade, du hast keinen Index auf ein Bit-Feld gesetzt)

Ich würde noch die Reihenfolge der Felder f_ez_monat und f_ez_jahr tauschen und den Index darauf löschen und neu erzeugen.
Dann kann man z.B. auch folgende Abfrage ausführen:
SELECT * FROM SCHWACKE_TDATA WHERE f_ez_jahr <= 1980 Weil das Jahr dann am Anfang des zusammengesetzten Index steht, würde der SQL-Server den Index benützen, auch wenn der Monat nicht in der Abfrage enthalten ist.

Ansonsten würde ich den Datentyp "nvarchar" nach "varchar" und "ntext" nach "text" ändern.
Die Datentypen, die mit "n" beginnen sind Unicodefähig und brauchen doppelt so viel Platz, wie die nicht Unicodefähigen Stringtypen.
In deinem Fall kannst du den Platzbedarf erheblich (geschätzte 35%) verringern.
Und ich glaube nicht, dass in den Schwackedaten Zeichen ausserhalb von ASCII verwendet werden. (Ausser die Chinesen werden zum weltgrössten Autoproduzenten und geben ihren Modellen chinesische Namen...

PS:
Achte darauf, dass alle Stringfelder vor dem Speichern in die Tabelle mit Trim() bearbeitet wurden;
du möchtest ja keine unnötigen Leerzeichen in Millionenstückzahl in der Datenbank haben.

[generic]

Warum die Indizes selbst anlegen, wenn das die Datenbank viel besser kann?!

Du zeichnest mit dem Profiler dein Programm auf.
Dann lässt du die Profilerdaten vom Queryanalyser checken.
Dieser gibt dann Empfehlungen und erzeugt sogar dein ein SQL-Script mit den empfohlenen Indizies und Statistiken.

[romber]

Vielen Dank für diese Tipps!

Nachdem ich alle ntext auf text geändert habe und die Reheinfolge für f_ez_monat und f_ez_jahr geändert habe, läufen die Anfrage nun so, wie ich mir vorgestellt habe.
Mit dem Profiler werde ich mich aber auch auseinandersetzen. Sehr interessant das alles.