Discussion :

[jjacques68]

bonjour à tous,

pour arriver à mes fins, j’utilise trois requêtes qui analysent 1 fichier de données de 20 000 lignes provenant de 20 000 fichiers excel.

ce fichier de donnée comporte une douzaine de rubrique de type texte essentiellement et d’une longueur de 26 caractères max.

la clé unique de la table est une rubrique automatique.

le but est de faire une analyse de ces données afin de les compter et les classer.

j’ai le résultat voulu, mais il me faut 5 bonnes minutes pour faire cette analyse.
Et c’est trop long !!!!

je vais essayer d’expliquer le procéder ... pas facile... :

j’utilise la requête 1 qui parcourt simplement le fichier de donnée pour ne ressortir que 20 d’enregistrments.
requête sans les doublons. (ça ça va c’est facile et rapide)

ensuite par code, je parcours 1 par 1 le résultat de la requête 1.
Avec la requête 2, dans le même fichier de données, je sors jusqu’à 10 000 enregistrements, selon une rubrique de la requête 1.

pour finir, avec la requête 3, je parcours cette dernière sélection (10 000) 1 par 1, pour trouver les doublons (max 10).

j’anayse un par un ces doublons pour y trouver une info spécifique.
En même temps, j’ai plusieurs compteurs qui s’incrémetent pour des stat.
Je mémorise l’enregistrement analysé dans une variable tableau pour ne pas l’analyser s’il revient.

c’est vraiment pas facile à expliquer, j’espère que qqun à compris mon histoire et peut m’aider à optimiser mon analyse !

merci d’avance !!!

[tbc92]

J'essaie de reformuler ce que tu fais actuellement :

Requete 1 : Select col1, col2 from monfichier where condition --> 20 lignes ; Ce n'est pas toi qui arrête la lecture pour n'avoir que 20 lignes, c'est la requete qui renvoie 20 lignes

Pour chacune des 20 lignes :
Requete 2 : Select col3 , col4 from monfichier where col1 = une_certaine_valeur.

requete 3 :
select col3 from requete2 group by requete2 having count(*) > 1

Ce que tu fais, ça ressemble à ça, mais ce n'est pas tout à fait ça. Peut-être que la syntaxe having count(*) > 1 va t'aider ?

Sinon, 2 conseils plus généraux :
- Tu peux lancer la commande hReindexe() sur ton fichier (ou regénérer les index via WDMAP). Parfois, ça permet d'améliorer nettement les performances, sans rien toucher au code.
- Tu peux lancer ton traitement en mode TEST, via le menu PROJET // Analyseur de PERFORMANCES.

L' Analyseur de PERFORMANCES va te donner un super compte-rendu, qui va te dire quelles étapes sont coûteuses. Ici, je ne suis pas convaincu que ça t'aide beaucoup. La solution est probablement de remplacer tes 1+20 + 20*1000 requêtes par une seule requête, mais en l'état, pas facile de t'aider plus.

[jjacques68]

merci pour ton aide !

pour le début c’est ok.

par contre

requete 3 :
select col3 from requete2 group by requete2 having count(*) > 1

j’ai pas ça ! c’est une simple requête, qui me sort donc les doublons de la rubrique...

je vais essayer ce que tu me dis...

[jjacques68]

d’après l’analyseur, c’est les hlitPremier() qui prennent le plus de temps...

[tbc92]

c’est une simple requête, qui me sort donc les doublons de la rubrique...

C'est à dire ? C'est quoi, une requête qui sort les doublons ? Jamais entendu parler de ce genre de requête (sous-entendu ... y'a un loup à creuser)

[jjacques68]

ben, j’execute la requête avec un argument, et il me sort tous les enregistrements, ayant cette valeur...

oui le mot doublon n’est peut être pas approprié...

[jjacques68]

pfff je me rends compte que je parcours 10 000 fois... 10 000 enregistrements...

faut que je change mon algo...

peut être qu’en faisant un tri sur la requête 2, puis de lire le premier enregistrement, mémoriser ma valeur, lire le suivant, et comparer avec le précédent...
je ferais qu’une seule passe sur les 10 000 records !

pourtant je suis sûr que l’on peut faire plus simple...

haaaaa, c’est vraiment pas simple à expliquer

[tbc92]

Là, ton idée générale, c'est : Je lance une requête 'basique' qui lit tout le fichier, je récupère tous les enregistrements , dans l'ordre qui va bien, et dans mon code Windev, je cherche les doublons ... ( ou ça peut être plein d'autres trucs, je fais une somme par exemple).
En terme de performance, c'est catastrophique.
On va prendre un peu de recul, et faire un truc très différent.
Tu as un fichier 'FACTURES' avec 2 colonnes : code client, montant ... et il peut y avoir plusieurs lignes pour le même client.
Tu veux connaitre le nombre de factures pour chaque client, et la somme totale facturée à chaque client.

Tu peux lire le fichier, et dans le code Windev , faire les additions.
Ou tu peux écrire une requete :
SELECT ID_CLIENT, count(*) as NB, sum (Montant) as Total from FACTURES group by ID_CLIENT

En terme de performance, c'est le jour et la nuit. Disons que tu divises ton temps de traitement par 5 ou 10.

Dans ton cas, c'est un peu similaire. Tu peux certainement écrire une requête qui va te donner directement le résultat voulu. En terme de programmation, tu vas avoir 15 lignes, au lieu de tout ton code. Et en terme de performance, ton traitement va durer quelques secondes.

Mais avant de t'attaquer à une requête complexe comme celle-ce, il faut lire quelques tutoriels sur SQL. Regarde ici : https://sgbd.developpez.com/cours/

[fouedusa]

Bonjour;

Dans des cas pareils il vaut mieux donner un exemple pour qu'on puisse comprendre et nous orienter, bref

Doublon : Vaut dire un ensemble de rubrique se répète avec des clés différentes

Exemple :
enreg 1 : ( 01, X, Y, Z)
enreg 2 : ( 02, X, Y, Z)
enreg 3 : ( 03, X, Y, Z)

la question qui se pose pourquoi Ajouter un enregistrement qui existe auparavant ?
Si tu peux faire une recherche de l’existence de l'enregistrement tu peux décider de l'ajouter ou pas, et tu n'aura pas recours à la 3ieme requête.
Sinon
tu dois faire recours à un fichier temporaire dans ta troisième requête
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
15
16
17
18
19
Lecture du premier enregistrement dans le fichier source
 
tant que ce n'est pas la fin de fichier source
 
   recherche de l'enregistrement dans le fichier temporaire
 
   s'il n'existe pas 
      l'enregistrer dans le fichier temporaire
   sinon // existe
      // Traitement : modifier d'autres rubriques ou rien faire tout dépend de ce que t'en a besoin
   fin de si
 
   suppression de l'enregistrement dans le fichier source
 
   lecture de l'enregistrement suivant dans le fichier source
 
fin tant que
 
Copier le fichier temporaire dans le fichier source

Bon Dev.

[Voroltinquo]

Bonjour,

la question qui se pose pourquoi Ajouter un enregistrement qui existe auparavant ?

Cela peut arriver par exemple lors d'un rachat/fusion de 2 entreprises ayant la même activité qui avaient chacune un fichier client.
M. Dupont peut être client de l'entreprise A et B.

[jjacques68]

tbc92, ton exemple est juste, mais imagine maintenant une rubrique date supplémentaire et devoir sortir également la date le plus ancienne !

fouedusa : j’ai essayé de passer par une table temporaire, mais même résultat...

[fosfore]

Juste comme 5mn sur 3 requêtes pour seulement 20000 enregistrements, ne serait-ce pas trop long ?

Peut-être faudrait il pas se reposer la bonne question, que veut-on réellement obtenir ? L'analyse en place est-elle judicieuse ?

Car si tu dois lancer ces requêtes imbriquées toutes les x minutes, tu vas te confronter à des soucis d'ordre utilisateurs, traitements suivants, etc ...

Bon courage dans ton optimisation

[tbc92]

question :
Tbc92, ton exemple est juste, mais imagine maintenant une rubrique date supplémentaire et devoir sortir également la date le plus ancienne !
Réponse :
SELECT ID_CLIENT, count(*) as NB, sum (Montant) as Total , min (DDate) as Date_la_plus_ancienne from FACTURES group by ID_CLIENT

[jjacques68]

Ah... ok... bon...

Je vais faire table RAZ et repartir à 0...

Je vous tiens au courant... merci !!

[Voroltinquo]

Bonjour,
Pourquoi ne pas prendre le problème à l'envers ?
Tu es en train de chercher, qui plus est en séquentiel, les tuples redondants.
En "élimininant" les tuples non redondants (i.e. dont le nombre est 1) condition par condition, tu réduirais au fur et a mesure le nombre d'enregistrements sur lesquels se fait la recherche.

[jjacques68]

YESSSSS !

Merci !!

Je suis passé de 5 bonnes minutes à 4 secondes.

J’ai effectivement utilisé un count dans la requête...
Je dois quand même passer par du code pour analyser d’autres compteurs, mais je parcours 1 seule fois les 10 000 données !

N I C K E L !

Merci encore !