Datenbankexperten wissen, dass ein ideales Design einer Tabelle in einem Microsoft SQL Server mit der Implementierung eines gruppierten Indexes einhergeht. Schauen wir uns die Empfehlungen für einen gruppierten Index an, finden wir regelmäßig folgende Hinweise für dessen ideale Eigenschaften:
- Kleiner Datentyp: Jeder nicht-gruppierte Index benötigt als Verweis zur Tabelle das Schlüsselattribut des gruppierten Indexes. Je kleiner der Datentyp, desto weniger Platz benötigt ein nicht-gruppierter Index.
- Eindeutige Werte: Ist ein Schlüsselattribut nicht eindeutig, müssen weitere 4 Bytes für einen UNIQUIFIER gespeichert werden. Damit erhöht sich der Speicherbereich für die Schlüsselwerte um 4 Bytes. Gleiches gilt für die Speicherung des Schlüssels in nicht-gruppierten Indexen.
- Statische Werte: Ein Schlüsselwert sollte sich nicht verändern, da der Datensatz ansonsten an einer anderen Stelle im Index wieder eingeordnet werden muss. Für ein stark frequentiertes OLTP-System bedeutet das einen nicht unerheblichen Aufwand im Transaktionsvolumen. Dies ist einer der Gründe für die Beliebtheit von IDENTITY()-Eigenschaften für das Schlüsselattribut.
- Fortlaufende Werte: Fortlaufende Werte gewährleisten, dass keine teuren Page Splits durchgeführt werden müssen. Sofern neue Datensätze immer am Ende der Tabelle eingetragen werden, müssen keine bestehenden Datensätze verschoben werden.
Viele Datenbanken folgen diesen Empfehlungen. Bei der Implementierung wird jedoch zu selten hinterfragt, ob nicht eventuell die Nutzung eines Heap, also nicht-gruppierter Daten, besser wäre.
Ein Heap ist eine Tabelle in Microsoft SQL Server ohne gruppierten Index [1], wobei Sie einen oder mehrere nicht-gruppierte Indexe für Heaps erstellen können. Die Daten werden ohne bestimmte Reihenfolge in einem Heap gespeichert, die Abfolge
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.