Discussion :

[tux2005]

Bonjour,

Je suis sous SQL Server 2005, et je voudrais avoir votre avis pour la création d'index nécessaire ou non.

Je sais qu'il ne faut pas abuser des index, qu'ils sont inutiles en cas de très petites volumétries, qu'il faut les placer sur des colonnes qui ont un minimum de doublon....
Mais je n'arrive pas à savoir si par exemple pour ma table PAYS (table de référence) avec 2 colonnes : id_pays et libelle_pays.
Est-il intéressant de créer un index sur la colonne libelle_pays ?

Sachant :

• Il y a déjà un index primaire (cluster) sur id_pays qui est la clé primaire.
  
• La table contiendra la liste d'environ 200 pays (60 octets max par enregistrement)
• L'index servira dans un ORDER BY dans une requête assez souvent utilisée

Je me pose cette question pour la plupart de mes tables de références car elles sont assez souvent utilisées dans des order by sur leur libellé...

Je vous remercie par avance pour votre aide car j'ai effectué pas mal de recherche mais je n'arrive pas à répondre à cette question.

tux

[rudib]

Bonjour,

Il est bon de créer des index, même sur les petites tables. Il faut simplement que tu voies s'ils seront ensuite utilisés.

Les seules raisons de ne pas abuser des index sont qu'ils prennent de la place, et qu'ils ont un coût de maintenance, durant les mises à jour de la table. Ces deux cas sont peu importants dans le cas de petites tables.

Crée un index, regarde les différences de plan d'exécution entre la requête avant l'index puis après. Si le résultat est meilleur, conserve l'index.

Quelques pistes : http://rudi.developpez.com/sqlserver.../optimisation/

[tux2005]

Merci pour le lien et pour ta réponse, je vais pouvoir effectivement regarder ça de plus près.

Le coup des tables de petites volumétries me venait de ce site :
http://www.toutenligne.com/index.php...plain&menu=sql

et sinon j'avais déjà lu celui-là :
http://sql.developpez.com/optimiser/

mais etant donné que je n 'ai pas encore les volumétries de la production, je ne suis pas sur de pouvoir me baser sur les plans d'exécutions fournis avec des volumétries très faibles.

C'est pourquoi, je voulais savoir s'il y avait une "règle" pour les tables de références ? est-ce qu'en général, il est nécessaire de mettre un index sur le libellé ?

Mais avec ce que tu me dis, je peux mettre mon index sur le libellé sans qu'il n'y ait de conséquence en terme de maintenance car ceux sont des petites tables et elles sont très rarement mises à jour.

C'est bien ça ?

[rudib]

C'est ça. Une table de villes ne deviendra jamais gigantesque, à moins qu'on y entre tout et n'importe quoi.

[SQLpro]

Une idée est de synthéstiser toutes les tables de référence en une seule grosse par des union et d'indexer la vue. Il faut bien entendue que les tables de références aient les mêmes structures.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE VIEW V_ALLREFS_ARF (ARF_TRIGRAMME, ARF_ID, ARF_CODE,  ARF_LIBELLE, ARF_ORDRE
WITH SCHEMABINDING
AS
(SELECT 'PAY' AS PAY_ID, PAY_CODE, PAY_LIBELLE, PAY_ORDRE
 FROM T_R_PAY
UNION ALL
SELECT 'DPT' AS DPT_ID, DPT_CODE, DPT_LIBELLE, DPT_ORDRE
 FROM T_R_DPT
...
)
GO
 
CREATE UNIQUE CLUSTERED INDEX X_ARF ON V_ALLREFS_ARF (ARF_TRIGRAMME, ARF_ID)
GO
 
CREATE INDEX X_ARF_CODE ON V_ALLREFS_ARF  (ARF_TRIGRAMME, ARF_ID, ARF_CODE)
GO

A +

[tux2005]

ok merci pour ta réponse rudib.

Avec l'aide de ton lien, je viens de regarder le plan d'exécution de ma requete avant et après l'ajout de l'index sur le libellé et celui-ci est bien utilisé donc la requete est plus rapide car il y a une étape de tri en moins.
J'espère que cela sera pareil en production.

Merci pour ton aide

Tux

[tux2005]

je n'avais pas vu la réponse de SQL Pro...

Cela permet de gagner du temps pdt l'exécution, ta solution de créer un vue sur toutes les tables de références ?
Ou bien cela permet de gagner du tps en ne créant qu'un seul index ?

[SQLpro]

Pas seulement....

Cela permet aussi de placer toutes les références en cache côté client en une seule passe !

A +