Extension de la gestion des index du dictionnaire (412)
- Bertrand Littel
Les index utilisable
Les dictionnaire de données DHSD ainsi que XLAN en version Harmony 412 bénéficient de plusieurs nouvelles possibilités au niveau des index
index pur SQL : ce sont des index qui ont purement un usage d’amélioration des performances SQL sans impact métier
index pur XLAN : ce sont des index qui ont purement un usage métier et qui viendraient surcharger inutilement les index existants SQL
index recouvrant : ce sont des index dans lequels on ajoute des champs inutiles à la pure fonction d’indexage, mais qui pour des raisons métier sont ajoutés en couverture étendue à l’index pour que le moteur SQL permette de lire le champ sans re-interroger la base de données
Description des index ‘pur SQL’ et ‘pur XLAN’
Au niveau du dictionnaire DHSD, dans la vue des clés d’index, chaque index dispose de 2 nouvelles propriétés globales : Masqué pour SQL et Masqué pour XISAM
Masqué pour SQL | Masqué pour XISAM |
|
|---|---|---|
NON | NON | Valeur par défaut. Ils étaient ainsi avec cette fonctionnalité |
OUI | NON | Index métier, inutile dans SQL |
NON | OUI | Index SQL, inutile pour le métier |
OUI | OUI | Ne pas utiliser pour un index actif |
XLAN utilisait jusqu’ici le withindex pour forcer les index. Ce nouveau mécanisme permet de laisser plus de souplesse au moteur SQL pour choisir le meilleur index
Description des index recouvrants
Au niveau du dictionnaire DHSD, dans la vue des clés d’index, chaque index dispose d’un nouvelle propriété globale : Colonnes incluses
Le principe d’un index recouvrant est d’indiquer, pour le moteur SQL uniquement (aucun impact en index HFI), que des champs supplémentaires doivent être stockés dans la table interne SQL des index.
Ainsi, l’index qui utilise des champs présents pour ‘raisons techniques’ pour la bonne gestion des données, recouvre des champs ajoutés pour ‘raison fonctionnelle’.
Un exemple pour illustrer : l’index principal sur les réservations d’article en stock (MRES) est principalement constitué d’un recherche par ticket de réservation (TICKETRESS). Mais lorsqu’on utilise cet index, c’est fonctionnellement en général pour cumuler les quantités de réservation (RESQTE). La nouvelle propriété permet d’ajouter le champs RESQTE en inclusion de l’index.
Cela aura un impact sur les performances du moteur SQL, car il n’aura pas à relire en base (lookup) la ligne MRES trouvée par lecture d’index si cela concerne les champs inclus dans l’index recouvrant
Illustration XWIN pour l’index A de MRES : les champs RESQTE, CE3 et CE5 sont recouvrants, donc sans impact sur l’index lui-même, mais disponibles sans relecture par le moteur SQL
