Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement WinDev [WD10] rapidité requête

[WD10] rapidité requête

8 réponses
Avatar
JeAn-PhI
bonjour

je parcours une liste d'enregistrement et à chaque enreg j'exécute une
requête de vérif.

cette requête s'exécute en moyenne en 0.065s
la lecture de celle-ci s'effectue en moyenne en 10s alors qu'elle ne
contient aucun enreg

pourquoi ?

j'ai déjà vérifié l'optimisation les critères de sélection et tout est
OK

--
Cordialement JeAn-PhI
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
mat
JeAn-PhI wrote:
...
cette requête s'exécute en moyenne en 0.065s
la lecture de celle-ci s'effectue en moyenne en 10s alors qu'elle ne
contient aucun enreg


...

Bonjour,

supposant qu'on parle de HF, c'est que hExecuteRequete sous WD10
retourne le contrôle plus rapidement au programme que les versions
précédentes, je pense au moment que la requête a été vérifiée et passée
à un thread secondaire. Ensuite l'exécution continue dans ce thread. La
seule manière que j'ai trouvé de mesurer le temps total d'exécution
d'une requête est d'appliquer un hLitDernier au résultat. La lecture est
toujours rapide, ce qui traîne c'est l'exécution (surtout le tri) de la
requête. Quelqu'un disait une fois que les requêtes Windev sur HF sont
plus un filtre sur les fichiers source qu'une requête SQL classique. Ce
qui expliquerais des lenteurs lors de jointures sur multiples fichiers.

Salutations
Mat
Avatar
patrice
si on cherche à optimiser une requete, il faut la programmer à la mimine
avec les hlitrecherchepremier et consort.
sinon, c'est trop dépendant des jointures, des statistiques calculées ou
non, du nombre d'enregistrement et de la météo.

"JeAn-PhI" a écrit dans le message de
news:
bonjour

je parcours une liste d'enregistrement et à chaque enreg j'exécute une
requête de vérif.

cette requête s'exécute en moyenne en 0.065s
la lecture de celle-ci s'effectue en moyenne en 10s alors qu'elle ne
contient aucun enreg

pourquoi ?

j'ai déjà vérifié l'optimisation les critères de sélection et tout est
OK

--
Cordialement JeAn-PhI




Avatar
JeAn-PhI
patrice a utilisé son clavier pour écrire :
si on cherche à optimiser une requete, il faut la programmer à la mimine
avec les hlitrecherchepremier et consort.
sinon, c'est trop dépendant des jointures, des statistiques calculées ou
non, du nombre d'enregistrement et de la météo.

"JeAn-PhI" a écrit dans le message de
news:
bonjour

je parcours une liste d'enregistrement et à chaque enreg j'exécute une
requête de vérif.

cette requête s'exécute en moyenne en 0.065s
la lecture de celle-ci s'effectue en moyenne en 10s alors qu'elle ne
contient aucun enreg

pourquoi ?

j'ai déjà vérifié l'optimisation les critères de sélection et tout est
OK

--
Cordialement JeAn-PhI





il s'agit de HF

c'est fou quand même dans la requête j'ai une jointure sur 2 fichiers
et il met 10s pour me dire que la requête ne contient aucun résultat
(résultat attendu pour être traité).

le nb d'enreg dans :
Fic 1 : 6276 enregs et 37 rubriques
Fic 2 : 6276 enregs et 128 rubriques

la requête est comme ceci :
- Fic1.Rub1 clé unique dans les 2 fichiers
- Fic1.Rub2 clé doublons
- Fic2.Rub2 clé doublons
- Fic2.Rub3 clé doublons

SELECT
Fic1.Rub1
FROM
Fic1, Fic2
WHERE
Fic1.Rub1 = Fic2.Rub1
AND Fic1.Rub1 > {pParam1}
AND Fic1.Rub2 <> ''
AND Fic2.Rub2 = {pParam2}
AND Fic2.Rub3 <> 'Val1'
AND Fic2.Rub3 <> 'Val2'
ORDER BY
Fic1.Rub1

--
Cordialement JeAn-PhI
Avatar
mat
JeAn-PhI wrote:
...
il s'agit de HF

c'est fou quand même dans la requête j'ai une jointure sur 2 fichiers et
il met 10s pour me dire que la requête ne contient aucun résultat
(résultat attendu pour être traité).

le nb d'enreg dans :
Fic 1 : 6276 enregs et 37 rubriques
Fic 2 : 6276 enregs et 128 rubriques

la requête est comme ceci :
- Fic1.Rub1 clé unique dans les 2 fichiers
- Fic1.Rub2 clé doublons
- Fic2.Rub2 clé doublons
- Fic2.Rub3 clé doublons

SELECT
Fic1.Rub1
FROM
Fic1, Fic2
WHERE
Fic1.Rub1 = Fic2.Rub1
AND Fic1.Rub1 > {pParam1}
AND Fic1.Rub2 <> ''
AND Fic2.Rub2 = {pParam2}
AND Fic2.Rub3 <> 'Val1'
AND Fic2.Rub3 <> 'Val2'
ORDER BY
Fic1.Rub1






1) je metterais Fic1.Rub1 = Fic2.Rub1 plutot dans le FROM que dans le
WHERE. Cela ne changera peut-être rien, mais avec HF on ne sait jamais.

2) S'assurer que tu as des index sur toutes les valeurs de recherche,
même des booléens.

3) J'assume que Fic1.Rub1 a un index, mais essaye quand-même sans "ORDER
BY".

Mat
Avatar
patrice
"JeAn-PhI" a écrit dans le message de
news:

le nb d'enreg dans :
Fic 1 : 6276 enregs et 37 rubriques
Fic 2 : 6276 enregs et 128 rubriques

la requête est comme ceci :
- Fic1.Rub1 clé unique dans les 2 fichiers
- Fic1.Rub2 clé doublons
- Fic2.Rub2 clé doublons
- Fic2.Rub3 clé doublons

SELECT
Fic1.Rub1
FROM
Fic1, Fic2
WHERE
Fic1.Rub1 = Fic2.Rub1
AND Fic1.Rub1 > {pParam1}
AND Fic1.Rub2 <> ''
AND Fic2.Rub2 = {pParam2}
AND Fic2.Rub3 <> 'Val1'
AND Fic2.Rub3 <> 'Val2'
ORDER BY
Fic1.Rub1




et d'apres toi, il va faire un parcours sur rub1, rub2 ou rub3 ??
tout depend du nombre d'enregistrement ayant rub2={pParam2) (ca HF peut le
savoir si les stats de tes fichiers sont calculées)
sauf s'il y'en a moins ayant rub1>{pParam1} (et ca HF peut pas le savoir)

et une fois qu'il aura fait le parcours, il devra ensuite reclasser par rub1

donc mon conseil :
si HF est pas bete (ce qui est loin d'etre prouvé), faire une clé composée
commencant par RUB1 (pour éviter le tri), suivi des rubriques les plus
discriminantes), je dirais RUB2 puis RUB3
sauf si RUB2 est plus discriminant que RUB1 alors ca serait plutot
RUB2,RUB1,RUB3
et bien sur, calculer les stats sur les fichiers sinon HF est perdu dans ses
requetes.
Avatar
mat
JeAn-PhI wrote:
...
SELECT
Fic1.Rub1
FROM
Fic1, Fic2
WHERE
Fic1.Rub1 = Fic2.Rub1
AND Fic1.Rub1 > {pParam1}
AND Fic1.Rub2 <> ''
AND Fic2.Rub2 = {pParam2}
AND Fic2.Rub3 <> 'Val1'
AND Fic2.Rub3 <> 'Val2'
ORDER BY
Fic1.Rub1




j'ai oublié que dans un cas comme ci-dessus, dans mon expérience, sur HF
une sous-requête est généralement plus rapide qu'une liaison. Je sais
que les guru de SQL disent le contraire.

SELECT
Fic1.Rub1
FROM
Fic1
WHERE
Fic1.Rub1 IN (SELECT Rub1 FROM Fic2 WHERE Fic2.Rub1 = Fic1.Rub1)
AND Fic1.Rub1 > {pParam1}
AND Fic1.Rub2 <> ''
AND Fic2.Rub2 = {pParam2}
AND Fic2.Rub3 <> 'Val1'
AND Fic2.Rub3 <> 'Val2'
ORDER BY
Fic1.Rub1
Avatar
JeAn-PhI
mat avait soumis l'idée :
JeAn-PhI wrote:
...
il s'agit de HF

c'est fou quand même dans la requête j'ai une jointure sur 2 fichiers et il
met 10s pour me dire que la requête ne contient aucun résultat (résultat
attendu pour être traité).

le nb d'enreg dans :
Fic 1 : 6276 enregs et 37 rubriques
Fic 2 : 6276 enregs et 128 rubriques

la requête est comme ceci :
- Fic1.Rub1 clé unique dans les 2 fichiers
- Fic1.Rub2 clé doublons
- Fic2.Rub2 clé doublons
- Fic2.Rub3 clé doublons

SELECT
Fic1.Rub1
FROM
Fic1, Fic2
WHERE
Fic1.Rub1 = Fic2.Rub1
AND Fic1.Rub1 > {pParam1}
AND Fic1.Rub2 <> ''
AND Fic2.Rub2 = {pParam2}
AND Fic2.Rub3 <> 'Val1'
AND Fic2.Rub3 <> 'Val2'
ORDER BY
Fic1.Rub1






1) je metterais Fic1.Rub1 = Fic2.Rub1 plutot dans le FROM que dans le WHERE.
Cela ne changera peut-être rien, mais avec HF on ne sait jamais.



je vais essayer
2) S'assurer que tu as des index sur toutes les valeurs de recherche, même
des booléens.



c'est ce que j'ai :
- Fic1.Rub1 clé unique dans les 2 fichiers
- Fic1.Rub2 clé doublons
- Fic2.Rub2 clé doublons
- Fic2.Rub3 clé doublons





3) J'assume que Fic1.Rub1 a un index, mais essaye quand-même sans "ORDER BY".



cf 2)
Mat



--
Cordialement JeAn-PhI
Avatar
mat
mat wrote:

mes excuses, devrait lire

SELECT
Fic1.Rub1
FROM
Fic1
WHERE
Fic1.Rub1 IN (SELECT Rub1 FROM Fic2 WHERE Fic2.Rub1 = Fic1.Rub1
AND Fic2.Rub2 = {pParam2} AND Fic2.Rub3 <> 'Val1' AND Fic2.Rub3 <>
'Val2')
AND Fic1.Rub1 > {pParam1}
AND Fic1.Rub2 <> ''
ORDER BY
Fic1.Rub1