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 :

< Retour

2 commentaires

Julien
08/03/2018 - 21:06 - Répondre
Depuis quelques années vous semblez privilégié HFSQL C/S et cela se confirme avec la version 23... par exemple en déportant les outils d'optimisation des requêtes vers le C/S.... La très grande majorité des app développé en Windev que j'ai testé sont par défaut en HFSQL Classic. L'utilisation d'un C/S est lourd ( en installation et configuration) et pose de sérieux problèmes de compréhension des utilisateurs (sans connaissance en informatique)...

Loïc HAMEL
09/03/2018 - 08:26 - Répondre
L’utilisation d’une base HFSQL C/S doit être effectivement privilégiée. Que ce soit pour la sécurité de vos données ou pour la performance de vos applications. La base HFSQL Classique est maintenant plutôt adaptée à une utilisation en monoposte. L’installation et la configuration du serveur HFSQL peut être incluse automatiquement à l’installation de votre application. Les mises à jour de ce serveur est également proposée en automatique. C’est de loin la base de données la plus utilisée par les utilisateurs de WINDEV.

Publier un commentaire : 
Votre adresse email ne sera pas publiée