Index ordonnés en clusters (2)

problématique ? Hormis l’aspect volumineux et quelque peu incompréhensible des GUID, dans SQL Server 2000, la fonction qui génère les valeurs de GUID (newid()) ne crée pas de modèle à croissance continue, comme le ferait une colonne IDENTITY. La possibilité de créer un modèle à croissance continue ne constitue pas l’un des principaux critères que je recherche pour une clé d’index ordonné en clusters, mais cela procure de nombreux avantages. Sans modèle à croissance continue, vous aboutirez probablement à une table fragmentée, aux performances médiocres. Pour plus d’informations sur les GUID, consultez l’encadré « Utilisation de la fonction de génération de GUID newsequentialid() ».

Si la clé d’index ordonné en clusters augmente en continu, les nouvelles lignes disposent d’un emplacement spécifique. Si ce dernier est situé à la fin de la table, la nouvelle ligne doit se voir attribuer de l’espace, mais SQL Server n’a pas besoin de le faire au milieu de la table. Si une ligne est insérée à un emplacement ne disposant d’aucune place, SQL Server doit en faire. Ainsi, si vous insérez une ligne basée sur le nom de famille, il faudra faire de la place pour l’insertion du nom. Pour cela, SQL Server recourt au fractionnement.

Dans SQL Server, les fractionnements sont du type 50/50. Pour faire simple, 50 pour cent des données restent et 50 pour cent sont déplacés. L’index demeure ainsi intact du point de vue logique, même si ce n’est pas le cas physiquement. Lorsque le taux de fractionnement d’un index est élevé, celui-ci est qualifié de fragmenté.

Les colonnes IDENTITY constituent un bon exemple d’index à croissance continue et elles sont, en outre, intrinsèquement uniques, statiques et étroites. Un autre exemple est quelque chose qui remplit le maximum de critères possible, notamment une colonne datetime, voire encore mieux une clé composite associant les colonnes datetime et identity.