Discussion :

[cladoo]

Bonjour,

je souhaite accélérer les temps d'accès à ma base hyperfile CS lors de grosses requêtes SQL (je ne parle pas ici des HFiltre ou autre HLitRecherche* mais bien de requêtes SQL lancées avec HExecuteRequeteSQL), je me suis donc logiquement tourné vers les index et clés composées, cependant je ne suis pas certain d'optimiser correctement ces index, voici ma démarche :

- chaque rubrique pouvant faire l'objet d'un filtre dans ma requête est déclarée comme clé avec doublon (exemple sur une table Evènement : rubrique DateEvènement, rubrique TypeEvènement, rubrique GravitéEvènement : ces trois rubriques peuvent faire l'objet d'un filtre dans le bloc WHERE d'une requête SQL)

- je créé autant de clés composées que de combinaisons de clé avec doublons précédemment créées pouvant faire l'objet de filtres (exemple [DateEvènement + TypeEvènement] car ces 2 rubriques peuvent êtres filtrées simultanément dans le WHERE, ou encore [DateEvènement + GravitéEvènement + GravitéEvènement] pour les mêmes raisons)

Mes questions sont :
1) Si j'ai 3 rubriques indexées, et que plusieurs combinaisons de filtres peuvent être réalisées dans le WHERE : dois-je prévoir une clé composée pour chaque combinaison possible (exemple A+B, A+C, B+C, A+B+C) ou une 'globale' (A+B+C) suffit et fonctionne de la même façon ?

2) Est-ce que l'ordre de rubriques de la clé composée a une importance, si oui de quelle manière ?

3) Les critères Ascendant ou Descendant pour les index et les tris sur les rubriques composant les clés composées servent-elle uniquement à accélérer les tris et non pas les accès ? exemple si je cherche à accéder plus rapidement à mes derniers enregistrements (donc avec un filtre sur la rubrique DateEvènement , le fait d'être déclaré Ascendant ou Descendant pour la rubrique modifiera-t-il les accès (SELECT) ?

4) Y a-t-il un intérêt à faire une clé composée constituée par l'ID de la table et l'ID d'une clée étrangère à celle-ci (dans le but d'accélérer la jointure entre les 2 tables concernées) ?

EDIT : 5) Est-ce que la ré-indexation doit être lancée régulièrement (quelle fréquence ?) ou l'ajout/modif/suppression d'enregistrement garantit l'intégrité des index ? Autrement dit : est-ce que les index ne "s'émoussent" pas avec le temps si l'on n'intervient pas ?

Merci infiniment pour vos lumières

[Arnaud B.]

Bonjour,

Mes questions sont :
1) Si j'ai 3 rubriques indexées, et que plusieurs combinaisons de filtres peuvent être réalisées dans le WHERE : dois-je prévoir une clé composée pour chaque combinaison possible (exemple A+B, A+C, B+C, A+B+C) ou une 'globale' (A+B+C) suffit et fonctionne de la même façon ?

De mémoire seulement pour A+B (index couvrants). A vérifier.

Bonjour,

2) Est-ce que l'ordre de rubriques de la clé composée a une importance, si oui de quelle manière ?

Oui, privilégier la rubrique la plus discriminante en 1er.

Bonjour,
3) Les critères Ascendant ou Descendant pour les index et les tris sur les rubriques composant les clés composées servent-elle uniquement à accélérer les tris et non pas les accès ? exemple si je cherche à accéder plus rapidement à mes derniers enregistrements (donc avec un filtre sur la rubrique DateEvènement , le fait d'être déclaré Ascendant ou Descendant pour la rubrique modifiera-t-il les accès (SELECT) ?

Non il n'y aura aucun impact, inutile.

4) Y a-t-il un intérêt à faire une clé composée constituée par l'ID de la table et l'ID d'une clée étrangère à celle-ci (dans le but d'accélérer la jointure entre les 2 tables concernées) ?

Inutile.

EDIT : 5) Est-ce que la ré-indexation doit être lancée régulièrement (quelle fréquence ?) ou l'ajout/modif/suppression d'enregistrement garantit l'intégrité des index ? Autrement dit : est-ce que les index ne "s'émoussent" pas avec le temps si l'on n'intervient pas ?

Oui, il faut réindexer régulièrement (et pourquoi pas toutes les nuits si c'est un serveur, tant qu'à faire). Je n'ai pas d'explications sur le fait que les index ne soit pas toujours à jour, mais c'est un fait que j'ai constaté à +eurs reprises. Je pense qu'un index n'est mis à jour que dans certains cas, pour optimiser les insertions.

Je te conseille aussi de regarder le taux de densité des index (index dense = lecture rapide mais insertion lente)

Par ailleurs, ce qui joue grandement sur le temps d'exécution des requêtes, c'est, au delà des requêtes elles mêmes, la manière dont est conçu le modèle des données.
Pour faire court, il faut privilégier nombreuses tables avec peu de colonnes.

Cordialement, Arnaud Benhamdine.

[cladoo]

Merci beaucoup pour votre avis éclairé

De mémoire seulement pour A+B (index couvrants). A vérifier.

Je n'ai pas bien saisi : A+B ou A+B+C ?

[Arnaud B.]

L'index A+B+C couvre aussi l'index A+B (mais pas B+C, A+C...) : c'est séquentiel.

[cladoo]

Merci, je comprends mieux.