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.