Generell gilt, daß Indexes Datenabfragen enorm beschleunigen können. Nachteil aber ist, daß Änderungen an den Daten sich auch in Änderungen in den Indexes manifestieren, falls die entsprechenden Spalten, die von der Änderung betroffen sind, auch gleichzeitig Teil eines oder mehrerer Indexes sind. Indexes aber sind kein starres Konzept, von dem man nicht abweichen darf. So macht es zum Beispiel durchaus Sinn, vor dem Auffüllen einer Tabelle durch einen Massenimport, vorhandene Indexes auf der Tabelle zu löschen, um den Import zu beschleunigen und vielleicht innerhalb eines vorgegebenen Zeitfensters beenden zu können. Die Frage, ob in einem solchen Fall nicht besser die gesamte Tabelle gelöscht und neu erstellt wird, ignorieren wir an dieser Stelle. Sie ist ein eigenes Thema und nicht Gegenstand dieser Betrachtung.
Direktes Updaten der Systemtabellen ist eine der schnellsten Methoden, um SQL Server in die Irre zu führen. Daher sollte dies nur im Notfall angewendet werden:
In SQL 6.5 gibt es eine Einstellungen 'tempdb in RAM'. Ab Version 7 wird dies nicht mehr unterstützt. Microsoft ist der Ansicht, daß die internen Zugriffe genügend optimiert sind, um dies unnötig zu machen
Als Einleitung bemerkt, gibt es keine 'IDENTITY' Spalte. IDENTITY ist eine Spalteneigenschaft, die man einer Spalte vom Typ Integer und/oder Decimal mit scale(0) zuordnen kann. Eine andere Möglichkeit ist TRUNCATE TABLE. Nicht empfehlenswert für permanente Daten und funktioniert auch nicht immer.
ISQL.exe erkennt keine 'named instances'. Weitere Unterschiede werden in BOL aufgelistet.
Vielfach wird diese Frage gestellt, nachdem man Nicht-Administratoren den Zugang zu solchen Tools wie dem Enterprise Manager und/oder Query Analyzer gegeben hat.
Oftmals muss man schnell in der Lage sein, angeben zu können, mit welcher Version des SQL Server man arbeitet. Sei es, wenn man mit dem Microsoft Support telefoniert, sei es, um festzustellen, ob das aktuellste Service Pack installiert ist. Gründe gibt es genug.