Discussion :

[frenchsting]

Bonjour,

Je suis en train de faire un projet de migration de notre "ERP" maison vers un système imposé par notre groupe. Dans ce cadre, je suis amené à faire beaucoup de requêtes et de parcours sur celles-ci. La question existentielle que je me pose est résumable en un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
DateMax est date
POUR TOUT FichierAparcourir
  DateMax = "20010101"
  // Execution requete de recherche basée sur le fichier concerné - Je n'ai pas mis les tests de résultat d'exécution pour simplifier
  hExecuteRequeteSQL(sdReq,....)
  POUR TOUT sdReq
    SI sdReq.Date > DateMax alors
      DateMax = sdReq
    FIN
  FIN
 
  // Code de gestion du DateMax
  ...
FIN

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
POUR TOUT FichierAparcourir
  DateMax est date
  DateMax = "20010101"
  // Execution requete de recherche basée sur le fichier concerné - Je n'ai pas mis les tests de résultat d'exécution pour simplifier
  hExecuteRequeteSQL(sdReq,....)
  POUR TOUT sdReq
    SI sdReq.Date > DateMax alors
      DateMax = sdReq
    FIN
  FIN
 
  // Code de gestion du DateMax
  ...
FIN

Les 2 bouts de code vont donner le même résultat.
L'idée est de savoir si :
- L'un des 2 va être plus rapide (FichierAparcourir a 200 000) enregistrements (et donc générer 200 000 requêtes à exécuter + parcourir) ?
- La philosophie "du code propre" conseille le 2ème, dans le sens qu'une fois le parcours du fichier terminé, on n'en a donc plus besoin, et il ne sert à rien de laisser une variable devenue inutile en mémoire ?
- On s'en cogne ?
- Le gras, c'est la vie ?

Faîtes couiner vos mulots et braire vos claviers ! Un peu de philo par les temps qui courent, ça change du quotidien !

[tatayo]

Bonjour,
A mon avis, la différence ici sera plus que négligeable, le plus gros du temps sera pris par la requête.
Mais je vote pour la seconde version: si tu "déportes" le code dans une procédure, la variable sera locale à la procédure et ne servira que dans cette procédure.

D'ailleurs en lisant le code je me dis que la seconde boucle ne sert à rien, si tu cherches "la date max", autant mettre ce critères dans la requête pour qu'elle ne renvoie qu'une seul ligne: la plus grande date trouvée supérieure à dateMax.
Là je pense que la différence sera flagrante.

Tatayo.

[frenchsting]

Merci pour ta réponse tatayo,

Fusionner les 2 traitements, c'est ce que j'avais fait au départ, mais... Les jointures sur des gros fichiers ne sont pas le fort de HFCS. Tout du moins la base que nous utilisons. Les perfs sont non seulement lamentables mais en plus, ça empêche les collègues de bosser.

Alors, j'ai découpé "en petits morceaux", cette requête qui n'est pas maousse (genre juste une jointure). Ca me permet de voir l'avancée des traitements et de vérifier que ce que je remonte est suffisamment correct (des utilisateurs ont importé/saisi des données délirantes).

[tatayo]

En fait je voyais un truc du genre:

Code windev :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
POUR TOUT FichierAparcourir
  DateMax est date
  DateMax = "20010101"
  hExecuteRequeteSQL(sdReq,DateMax)
  SI hnbEnr(sdReq) > 0 ALORS
    DateMax = sdReq
  FIN
  // Code de gestion du DateMax
  ...
FIN

Et dans la requête, un petit test sur la date passée en paramètre. Il n'y a pas de jointure en plus, juste un test.

Tatayo.

[frenchsting]

Merci pour ce conseil. Mais j'ai simplifié le code à l'extrême. En fait, elle ressemble plutôt à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT Id,  MAX(DateCrit) AS MaxDateCrit
FROM Table
WHERE id IN (%1) AND crit IN (%2) AND DateCrit < '%3'
GROUP BY Id

Pour n id, on doit avoir au moins un crit pour lequel la DateCrit < date (DuJour)
n vaut entre 2 et 10.
Pour crit, il y a une vingtaine de valeur.
Il y a des dates saisies qui sont délirantes (genre 01/01/2345). Certes, je pourrais mettre un BETWEEN pour les dates, mais je ne pense pas que j'y gagne vraiment.

Le résultat va me renvoyer au max n id. Ce qui m'intéresse, c'est l'id avec le max du MaxDateCrit.

[EDIT]
- Après optimisation du code lors du parcours de FichierAparcourir, je tombe à environ 550 requêtes à générer/traiter. Le temps est tout à fait acceptable (50 secondes environ).
- Je passe en résolu (la question de départ n'était pas l'optimisation de la requête)

Merci d'avoir pris le temps de lire ma prose.

[Jon Shannow]

Pardon, d'arriver après la bataille, mais y a un truc que je ne comprends pas.

Quel est l'intérêt de déclarer une variable au sein d'une boucle, plutôt que la déclarer à l'extérieur, c'est à dire une seule fois !

JS

[tbc92]

De manière générale, quand on peut faire une seule requête plutôt que 50 ou 200000, on est gagnant.
Je ne sais pas si cette syntaxe est acceptée par HFSQL, et je ne sais pas non plus si c'est bien le besoin, mais je propose :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Update Table
set DateCrit = Maxd 
where (id, DateCrit) in 
( 
  SELECT Id,  MAX(DateCrit) AS MaxDateCrit  
  FROM Table
  WHERE id IN (%1) AND crit IN (%2) AND DateCrit < '%3'
  GROUP BY Id
)

[tatayo]

Si tu cherches l'id avec la date max, le mieux serait de trier la requête sur la date, et de ne lire que la première ligne.
Ou de revoir la requête pour ne renvoyer qu'une ligne. Escartefigue nous a fait un article sur ce genre de requête.

Tatayo.

[frenchsting]

Pardon, d'arriver après la bataille, mais y a un truc que je ne comprends pas.

Quel est l'intérêt de déclarer une variable au sein d'une boucle, plutôt que la déclarer à l'extérieur, c'est à dire une seule fois !

JS

Hello Jon,
C'était la question de départ

Je pense la même chose, mais le W-Langage, pour ressembler aux langages dans l'air du temps, pique des idées à ceux-ci. Cela inclut donc les variables à portée locale (dans une condition, une boucle). Autant, dans une condition, elle est déclarée une seule fois, autant pour une boucle, c'est n fois (dans mon cas 200 000 fois).

Addendum : Pour (me) répondre, je me suis aperçu que vu le nombre de boucles à effectuer (il y en a finalement 200 000), je gagne quelques secondes sur un premier échantillon de 10 000. Logiquement, à la fin, je devrais être sur quelques minutes car le temps de traitement total estimé est de plus de 40 minutes.

@tatayo : Concernant la proposition de tri, elle est très bonne. Cela m'évite de faire la boucle sur le résultat. Je n'y avais pas pensé sur le coup mais je pense que j'y serai venu. Merci à toi

@tbc92 : Connaissant le SQL HF, je ne me hasarderai pas la dessus. Même si ton idée est très bonne. Merci à toi également pour cette proposition.

Pour préciser : au départ, j'avais fait une requête unique et filtré sur le résultat. Sauf que comme je l'avais précisé en premier lieu, l'exécution pénalise les utilisateurs, est très lente (voire plante le serveur). Ma solution est "belle" mais ça a le mérite de fonctionner...

[kuranes]

Ma question tombe peut être à plat, mais pour optimiser tout ça, est ce qu'une utilisation des tâches parallèles ne serait pas pertinente ?

[frenchsting]

Bonjour,

@kuranes : c'est une piste que je n'ai pas explorée du tout. Les perfs du serveur sont assez aléatoires, et je doute que d'envoyer 200 000 requêtes en "simultané" soient gérables par la bête. Mais merci pour cette idée.

La solution que j'ai retenue :
- Pour me répondre à ma question que je m'ai posée : Sauf cas exceptionnel (dans une condition notamment), je déclare mes variables en début de bloc de code !
- Pour ce qui est de mon code proprement dit, je fais 3 parcours globaux : un pour fichierAParcourir => tableau associatif, un pour ma requête (sans ma clause Id IN) => tableau associatif, un pour chercher la correspondance entre les 2 tableaux associatifs.

J'arrive à des perfs plus que convenables.

Merci à vous tous