Discussion :

[Kropernic]

Hello,

J'aimerais avoir votre avis sur ce qui est dit dans cet article.

Personnellement, je me borne à laisser l'index cluster sur la clef primaire de la table (dans 95% des cas, une colonne int identity(1,1)).

Qu'en est-il des pratiques de nos MVP's et autres pros du secteur ?

[darkelend]

Ca dépend des statistiques d'utilisation des indexs de ta table.
Une piste : si tu as un clustered index avec très peu de seek et beaucoup de LookUp + un non clustered index avec beaucoup de seek, ca pourrait être intéressant de convertir ta pk en non clustered et passer l'autre index en clustered.

[SQLpro]

Effectivement il y a des cas ou l'index clustered n'est pas satisfaisant.

Les cas d'insatisfaction sont les suivants :

• clef longue ou composée de nombreuses colonnes
• valeurs très arbitraires
• clef fréquemment mise à jour

En effet, la valeur de la clef clustered va être reprise dans les autres index. Si elle est longue elle pèse sur chacun des index secondaires. Si elle est composée, les statistiques sont moins bonne (seule la 1ere colonne est "statitisée").
Si les valeurs sont très arbitraires (donc non monotone) alors la table se fragmente vite (l'index clustered étant la table), De même en cas d'UPDATE.

D'autre part l'article fait des métriques qu'en ce qui concerne le lookup et se focalise sur une problématique. C'est l'arbre qui cache la forêt !

A +

[Kropernic]

@darkelend :

bien compris

@sqlpro :

En normalisant correctement et en faisant plaisir à Mr Tabourier, on obtient alors (à l'exception des tables résultant d'une association n à n) que des clefs qui ne sont pas composées, qui ne varient pas et qui ne sont pas aléatoires.
Cela s'applique-t-il alors encore ?
Mais je note ta remarque concernant le fait que l'article ne traite que des key lookup.

[SQLpro]

@darkelend :

bien compris

@sqlpro :

En normalisant correctement et en faisant plaisir à Mr Tabourier, on obtient alors (à l'exception des tables résultant d'une association n à n) que des clefs qui ne sont pas composées, qui ne varient pas et qui ne sont pas aléatoires.
Cela s'applique-t-il alors encore ?

Non, mais si la table d'association n/m comporte de nombreuses colonnes clef, alors on peut la transformer en une table avec une clef auto CLUSTERED (par défaut) + contrainte UNIQUE (donc index non clustered).

Mais je note ta remarque concernant le fait que l'article ne traite que des key lookup.

Et oui....

A +