CLUSTERED vs indice couvrant

Question

Tenir compte le tableau suivant dans SQL Server 2008:

LanguageCode varchar(10) 
Language  nvarchar(50) 

LanguageCode participe à des relations, donc je ne peux pas créer un index de clé primaire qui comprend les deux colonnes (LanguageCode, langue).

Si je mets une clé clustered primaire sur LanguageCode, bien sûr, je ne peux pas inclure la langue dans l'index (index de couverture). Cela signifie que je vais devoir créer un deuxième index pour la langue, ou courir le risque d'avoir des doublons dedans (plus forcer un balayage de table pour récupérer sa valeur).

En outre, la documentation de MS (ainsi que des experts en la matière) indiquent qu'un tableau devrait idéalement avoir un index en cluster.

Dans ce cas, un index de couverture non groupé (LanguageCode, Language) garantirait non seulement que la langue est unique, mais éviterait l'analyse de la table. Cependant, il n'y aurait pas d'index clusterisé "idéal".

Est-ce un de ces cas où l'absence d'index clusterisé est idéale?

Modifier en fonction des commentaires:

La seule question que je veux courir est:

SELECT Language, LanguageCode FROM Languages where Language="EN" 

Answer 1

index cluster, par définition, couvre toutes les colonnes.

Si vous créez un PRIMARY KEY CLUSTERED sur LanguageCode et un UNIQUE INDEX sur Language, il vous permettra de rechercher une langue à la fois par son code et son nom avec une seule recherche, et, en plus, faire Language unique.

Answer 2

1. Il n'est pas nécessaire d'inclure des colonnes sur un index clusterisé. Puisque l'index clusterisé est "les données", toutes les colonnes sont automatiquement incluses.

2. Si vous avez besoin d'effectuer une recherche par Langue et/ou de vous assurer de son unicité, alors créez un index supplémentaire.

Answer 3

Sur la base de la nature du sujet (que je devine est langues parlées par les humains), l'indexation pour la performance va être hors de propos. Si vous aviez 100 langues et que chaque ligne prenait 120 octets (pseudo-factorisation dans les en-têtes varchar, les masques de bits null et autres joyeusetés), vous auriez 12 000 octets de données, ce qui correspond à deux pages de 8 ko. SQL ne prendra pas la peine d'utiliser des index sur quoi que ce soit de si petit, il va simplement numériser le tout (2 pages) et le forcer brutalement, en demandant moins de temps que ce que l'on peut facilement mesurer.

Indexation pour assurer l'unicité, bien sûr, je le fais tout le temps. Mais pour la performance, jusqu'à ce que vous atteignez 3 pages (ou 4), cela n'a pas d'importance. (Ce qui se passera si vous suivez les langages de programmation, car il y en a une douzaine de nouvelles chaque semaine.)