Discussion :

[droliprane]

Bonjour,

je reviens auprès de vous pour avoir votre avis éclairé sur la pertinence de l'utilisation des fonctions HFiltre comparée à l'utilisation de requête paramétrée.

Je donne un cas d'utilisation : J'ai une liste de commandes, et quand je clique sur une commande je veux afficher toutes les livraisons effectuées sur la dite commande. En production, on peut imaginer que j'aurai une vingtaine de commandes (de 5 lignes en moyenne) rentrées par mois, et environ 10 BL par jour.

Je vois 2 possibilités, il y en peut-être d'autres :

1) je fais un requête hyper générique : SELECT * FROM bl;
que je filtre à chaque fois par un HFiltre sur le critere bl_commande = ma_commande_selectionnée

2) je fais une requête paramétrée, que je réexécute à chaque changement de commande, mais avec le paramètre ma_commande_sélectionnée


J'aimerais savoir dans chacun des cas, ce qui est avantageux et ce qui l'est moins, enfin ce qui est plus ou moins couteux en resource, en temps d'exécution, .... histoire de ne pas voir mon programme grignotter au fur et à mesure le peu de ram que peuvent avoir certaines machines, ou solliciter le processeur plus que de raison...

Merci à vous.

[Nicolas_Jeanneau]

Bonjour,

déjà il faudrait savoir sur quelle base de données sont stockées les infos et si tu as l'habitude des requêtes SQL ou pas. Si tu es à l'aise avec les requêtes et que tu n'as pas du HF classique ou C/S, dans ce cas ne t'embêtes pas et lances des requêtes que tu parcoures ensuite.
Si tu es avec des fichiers HF, alors tu peux utiliser les fonctions H qui interagissent bien avec les données stockées sous ce format.

Pour les perfs, cela dépend beaucoup du serveur sur lequel elles sont stockées et des perfs réseau pour les atteindre.

à bientôt,

Nicolas

[frenchsting]

Personnellement, pour les commandes/livraisons, je fais une requête paramétrée.
La requête est utltra-basique (car sur une table) et du coup, les performances sont là.

A voir après sur une table de 1 million d'enregistrements, mais avec des hfiltre ou hlitrecherchepremier, on doit avoir des temps de réponse similaires.

[droliprane]

Nicolas : alors je bosse sur SQL Server et ça fait plus de 10 ans que je fais du SQL mais pas du transact SQL, mais bon je pense manipuler assez bien les requêtes.

Frenchsting : oui si ma requête me ramène 1 million de lignes de BL je me demande laquelle des méthodes se comporte le mieux....

Enfin d'une manière générale, quand un fait une requete sql sans paramètre est-ce qu'on est certain qu'elle ne va être exécutée qu'une seule fois (vis à vis du moteur de base de données) et qu'en suite c'est le HFiltre qui HDésactiveFiltre qui est géré en interne par les bibliotheques windev ? Ou bien il y a quand même requetage de la base en arrière plan ?

[WDKyle]

Salut,

Si ton but est de gagner du temps et performances, récupère seulement les données nécessaire à chaque étape.

Si dans un premier temps tu veux juste lister la liste de tous les bon de commandes (c'est çà ?) et bien fait une requête qui récupère juste quelques infos comme l'ID, le nom, ref par exemple.

Et seulement après (lorsque l'utilisateur souhaite voir toutes les infos d'un bon de commande) tu fais une requête paramétrée sur un bon de commande precis.

Moi je procède comme ça avec tous mes logiciels

[droliprane]

Bon c'est vrai que dans un premier temps, et simplement parce que je veux m'assurer que le code fonctionne, j'ai tendance à faire des requêtes larges en SELECT * alors que j'ai peut-être besoin de seulement 3 champs sur 10 !

Mais je me garde cette marge d'amélioration pour ensuite faire le tour de mes requêtes et les optimiser....

C'est sur qu'il faut garder ça dans un coin de sa tête.

[Nicolas_Jeanneau]

de toute façon, ton serveur SQL va stocker ta requête et son résultat pendant pas mal de temps donc si tu réexécutes la requête, les fois suivantes seront plus rapides. C'est le propre du serveur SQL. Maintenant si tu peux ne prendre que les lignes qui sont bonnes et ne pas avoir de filtre ensuite, c'est mieux.