La majeure partie des applications qui utilisent HFSQL accèdent maintenant aux données via le moteur HFSQL client/serveur. L'utilisation d'accès par une technologie client/serveur est en effet très vivement recommandée par rapport à un accès en partage.
Pour les applications qui utilisent encore un accès direct aux données HFSQL (HFSQL classic – ISAM), dans le cas général les données sont stockées dans un emplacement sécurisé modifiable, disque local ou partage réseau, afin de permettre l'enregistrement d'informations.
Mais il est également possible d'inclure des données HFSQL classic directement dans la bibliothèque (WDL) d'un exécutable, lorsque l'on souhaite proposer des données figées en consultation seulement.
Peu d'applications utilisent ce mécanisme puisque généralement les données sont modifiables. Ce billet le détaille cependant, car toutes les applications sont impactées par ce mécanisme. En effet, afin de permettre l'utilisation de données HFSQL classic intégrées à un exécutable, lors de l'accès à un fichier il y a d'abord sa recherche dans l'exécutable. Si cette recherche ne trouve les données HFSQL intégrées, alors les donnée sont utilisées le disque à l'emplacement spécifié par HChangeRep.
De ce mécanisme découlent deux optimisations importantes pour toutes les applications qui exploitent traditionnellement les données sur disque :
-
la principale concerne la recherche des fichiers de données dans l'exécutable. En fonction du nombre d'éléments du projet, la recherche des fichiers de données peut être coûteuse en temps. Il est donc possible d'indiquer à HFSQL classic qu'il ne doit pas rechercher les fichiers HFSQL dans l'exécutable, grâce à la fonction HChangeLocalisation :
// Ouverture du projet, avant l'accès aux données :
HChangeLocalisation("*",hDisque).
Le gain n'est pas significatif pour les projets ayant une centaine d'éléments. Il devient très intéressant dès que le projet a au moins 1000 éléments.
- la seconde optimisation concerne la conservation de la localisation des données utilisées via le fichier .REP. Dans le cas d'une application utilisant plusieurs jeux de données, l'accroissement progressif de la taille du .REP peut impacter les temps d'accès. Il est donc possible d'optimiser les accès en supprimant régulièrement du .REP les emplacements obsolètes, et/ou en inhibant sa gestion par HGèreRep lorsque c'est possible.
Autres billets abordant ce sujet :
|