Man sollte stets den kleinsten Datentypen auswählen, der ausreicht, um die Daten zu speichern. Die Gründe dafür sind einfach und einleuchtend:

• Je kompakter die Daten sind, desto mehr Daten passen auf eine Datenseite. Also ist SQL Server in der Lage mit jeder einzelnen IO Operation mehr Daten aufzunehmen, was wiederum dazu führt, daß auch weniger IO Operationen benötigt werden, um eine Aufgabe auszuführen.
• Je kompakter die Daten sind, umso weniger Daten müssen vom Server auf den Client geschafft werden. Dadurch wird der Netzwerkverkehr und Latenzen verringert.
• Eine Spalte wird schneller sortiert, je schmaller sie ist. Dies gilt besonders für die Zeichenfolgen Datentypen.
• Die belegte Speichermenge im Buffer Cache wird verringert. Dadurch können mehr Daten gecached werden.

*****

Auch wenn es vielleicht selbstverständlich ist, sollte man für Spalten mit deren Werten man Berechnungen anstellen will, einen der nummerischen Datentypen des SQL Servers wählen. Immer wieder kann man beobachten, das solche Daten in Zeichenfolgen Datentypen gespeichert werden. Die Wahl eines nummerischen Datentypen hat den Vorteil, das keine Konvertierung (explizit oder implizit) notwendig ist, um mit den Daten rechnen zu können.

*****

 NVARCHAR oder NCHAR sollten nur dann verwendet werden, wenn man unbedingt Unterstützung für Unicode Zeichen braucht. In allen anderen Fällen ist der Einsatz eine Verschwendung von SQL Server Resourcen. Da sie doppelt soviel Speicherplatz belegen, muß SQL Server unnötig viele I/O Operationen durchführen. Ferner belegen sie unnötig viel Platz im Buffer Cache.

*****

Variieren die Daten in Textspalten deutlich in Länge, ist der Einsatz von VARCHAR gegenüber CHAR vorzuziehen. Dadurch das VARCHAR nur die tatsächlich eingegebene Anzahl an Zeichen belegt, kann man deutlich an Speicherplatz sparen. Was wiederum I/O Operationen spart und damit die allgemeine Performance erhöht.

Ein weiterer Vorteil von VARCHAR ist, daß solche idR schneller sortiert werden können als CHAR Spalten, da SQL Server nur die tatsächlich belegten Zeichen sortieren muß und nicht die gesamte Länge der Spalte.

*****

Variieren die Daten einer Spalte jedoch nicht deutlich in Länge, sollten man den Einsatzt von CHAR in Betracht ziehen. Üblicherweise können solche Daten mit einer CHAR Spalte schneller verarbeitet werden.

*****

FLOAT (oder REAL) Datentypen sind nicht für PRIMARY KEYs geeignet. Nicht nur haben solche Spalten eine unnötigen Overhead, es existieren auch diverse KB Artikel zu Problemen bei FLOAT Daten in Indizes.

*****

Verwendet man Zeichendatentypen fester Länge (CHAR oder NCHAR), sollte man nach Möglichkeit vermeiden, NULL dort zu speichern. Zeichenfolgen Spalten fester Länge belegen immer den vordefinitierten Platz, egal was dort gespeichert wird. Es ist also eine immense Speicherplatzverschwendung, wenn man in einer CHAR(50) Spalten einen NULL Marker speichert. In solchen Fällen macht es mehr Sinn, einen Datentypen variabler Länge zu verwenden.

*****

Normalerweise ist vom Einsatz berechneter Spalten eher abzuraten, da sie Normalisierungsregeln verletzen. Aber manchmal kann es auch effizienter sein, eine solche Spalte einzusetzen als immer wieder diese Berechnung in Abfragen durchzuführen. Dies gilt umsomehr für Berechnung in Abfragen, die sehr häufig ausgeführt werden. Durch ein berechnete Spalte kann man hier die allgemeine Arbeit, die SQL Server verrichten muß, deutlich reduzieren. Allerdings sollte man stets im Einzelfall entscheiden, ob eine berechnete Spalte sich lohnt.

*****

Der SQL_VARIANT Datentyp mag zwar wie eine eierlegende Wollmilchsau erscheinen, bietet aber mehr Nachteile als Vorteile. Er sollte nach Möglichkeit vermeiden werden.

*****

Hat man eine Spalte, von der man im Vorfeld weiß, daß diese Daten häufig sortiert werden müssen, sollte man versuchen, diese Spalte INTEGER basiert zu erstellen, nicht Zeichenfolgenbasiert. Integers lassen sich wesentlich einfacher und schneller sortieren als Zeichenfolgen.

*****