WD12 et MySQL

Le
I.G.LOG
Bonjour

J'ai une appli avec accès natif MySQL.
Sur les tables fichiers la recherche avec loupe est très longue. A titre
d'exemple, une recherche avec la loupe de la réf. "B-3339" sur un fichier
articles contenant 100.000 enreg. prend environ 15 secondes les
utilisateurs râlent bien sur.
Le problème vient du fait que j'ai un filtre sur le fichier positionné avec
le code suivant:

gFiltre = "IDTYPE = 4 et TERMINE = 0"
hFiltre(TABLE..FichierParcouru,TABLE..RubriqueParcourue,Caract(0),Caract(255
),gFiltre)

Ce filtre permet de sélectionner les article de type "article" (IDTYPE = 4)
toujours actifs (TERMINE = 0).
IDTYPE est indexé, TERMINE est non indexé. La rubrique de parcours REFCONST
est indexée.

Sans le filtre, la recherche s'effectue 2 fois plus vite (ce qui n'est pas
génial non plus d'ailleurs)

Voyez vous une solution pour que la recherche soit plus rapide ?

Merci à tous
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
patrice
Le #14519961
salut
as tu essayé en ajoutant une clé composé (idtype,termine,refconst) ?

"I.G.LOG" news:47fb1416$0$858$
Bonjour

J'ai une appli avec accès natif MySQL.
Sur les tables fichiers la recherche avec loupe est très longue. A titre
d'exemple, une recherche avec la loupe de la réf. "B-3339" sur un fichier
articles contenant 100.000 enreg. prend environ 15 secondes... les
utilisateurs râlent bien sur.
Le problème vient du fait que j'ai un filtre sur le fichier positionné


avec
le code suivant:

gFiltre = "IDTYPE = 4 et TERMINE = 0"



hFiltre(TABLE..FichierParcouru,TABLE..RubriqueParcourue,Caract(0),Caract(255
),gFiltre)

Ce filtre permet de sélectionner les article de type "article" (IDTYPE 4)
toujours actifs (TERMINE = 0).
IDTYPE est indexé, TERMINE est non indexé. La rubrique de parcours


REFCONST
est indexée.

Sans le filtre, la recherche s'effectue 2 fois plus vite (ce qui n'est pas
génial non plus d'ailleurs)

Voyez vous une solution pour que la recherche soit plus rapide ?

Merci à tous




Daniel
Le #14519941
I.G.LOG a écrit :
Bonjour

J'ai une appli avec accès natif MySQL.
Sur les tables fichiers la recherche avec loupe est très longue. A titre
d'exemple, une recherche avec la loupe de la réf. "B-3339" sur un fichier
articles contenant 100.000 enreg. prend environ 15 secondes... les
utilisateurs râlent bien sur.
Le problème vient du fait que j'ai un filtre sur le fichier positionné avec
le code suivant:

gFiltre = "IDTYPE = 4 et TERMINE = 0"
hFiltre(TABLE..FichierParcouru,TABLE..RubriqueParcourue,Caract(0),Caract(255
),gFiltre)

Ce filtre permet de sélectionner les article de type "article" (IDTYPE = 4)
toujours actifs (TERMINE = 0).
IDTYPE est indexé, TERMINE est non indexé. La rubrique de parcours REFCONST
est indexée.

Sans le filtre, la recherche s'effectue 2 fois plus vite (ce qui n'est pas
génial non plus d'ailleurs)

Voyez vous une solution pour que la recherche soit plus rapide ?

Merci à tous





Peut être mettre un index sur la rubrique parcourue?

Pour Termine je suppose que la valeur est 1 ou 0 dans ce cas pas besoin
d'indexer.



--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
I.G.LOG
Le #14519931
> salut
as tu essayé en ajoutant une clé composé (idtype,termine,refconst) ?




Bonjour,
Je voudrais - si possible - éviter les clés composées.
De plus, la table peut être triée sur 4 rubriques:
REFCONST (référence constructeur), DESIGNATION (désignation article),
IDARTICLE (identifiant) et REFINT (référence interne)...
voire plus car on peut effectuer des recherches par constructeur et autres
champs.

J'ai remarqué que le positionnement par hLitRecherche() est beaucoup plus
rapide. J'ai pensé à désactiver la recherche par loupe. Mais je perd le côté
pratique de ce système. Y a t il un moyen de gérer son propre code de
recherche dans la loupe ?

Encore merci
Daniel
Le #14519921
I.G.LOG a écrit :
salut
as tu essayé en ajoutant une clé composé (idtype,termine,refconst) ?




Bonjour,
Je voudrais - si possible - éviter les clés composées.
De plus, la table peut être triée sur 4 rubriques:
REFCONST (référence constructeur), DESIGNATION (désignation article),
IDARTICLE (identifiant) et REFINT (référence interne)...
voire plus car on peut effectuer des recherches par constructeur et autres
champs.

J'ai remarqué que le positionnement par hLitRecherche() est beaucoup plus
rapide. J'ai pensé à désactiver la recherche par loupe. Mais je perd le côté
pratique de ce système. Y a t il un moyen de gérer son propre code de
recherche dans la loupe ?

Encore merci





La difficulté est de savoir comment fonctionne les tables Windev et la
recherche.

De mon coté j'utilise uniquement les tables mémoires, et pour faire des
recherches j'appelle une boite de recherche pour recharger la/les valeur(s).

--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
I.G.LOG
Le #14519911
> Peut être mettre un index sur la rubrique parcourue?

Pour Termine je suppose que la valeur est 1 ou 0 dans ce cas pas besoin
d'indexer.





Bonjour,
La rubrique parcourue (REFCONST) est bien indexée !
Merci
patrice
Le #14519901
"I.G.LOG" news:47fb21cd$0$869$
> salut
> as tu essayé en ajoutant une clé composé (idtype,termine,refconst) ?
>

Bonjour,
Je voudrais - si possible - éviter les clés composées.



faut savoir ce que tu veux....
les clés composés servent à accélerer les recherches multicriteres

si tu a une table avec de rubrique indexé R1 & R2
une recherche sur R1=v1 et R2=v2 introduit normalement :
acces sur index R1=v1
Parcourir tous les enregistrements, renvoyer tous les élements dont
R2=v2
d'ou les temps de recherche.....

si tu as une table avec une clé composé (R1,R2)
une recherche sur R1=v1 et R2=v2 introduit normalement :
acces sur index (R1,R2)=(v1,v2)
renvoyer les enregistrements

donc pour résumer:
si tu veux accelerer: => clé composé
(ou alors charge tout en mémoire)
Firetox
Le #14519891
Bonjour,

les cles composées n'existent pas en SQL !
c'est une invention des bae fichier pour accelerer les ecture

dans votre requete Windev va faire avec le filtre :
gFiltre = "IDTYPE = 4 et TERMINE = 0"
hFiltre(TABLE..FichierParcouru,TABLE..RubriqueParcourue,Caract(0),Caract(255
),gFiltre)

le filte porte sur la cle ensuite parcour des enreg et on retient ques les
IDType=4 et TErmine = 0
c'est pour ca que patrice vous demande de faire une cle composée car a ce
moment la ce sera le parcours sur cette cle

en SQL il faudrait un index sur Primary +IDType+TERMINE et non des indece
separé car MySQL parcourra touours sur une cle primaire s'il estime que
l'index n'est pas optimal
donc dans votre casz il parcour sur la primary et regarde les IDType et
termine

il faudrait arrive a prendre la requete que windev genere et la mettre dans
SQLyog et faire un explain pour voir quel index MySQL va utilisé mais je
pense que c'est la primary qu'il prend donc il faut rajouter un index qui
est la primary + idtype + terminé

@+


"patrice" news: 47fb2a5d$0$19111$

"I.G.LOG" news:47fb21cd$0$869$
> salut
> as tu essayé en ajoutant une clé composé (idtype,termine,refconst) ?
>

Bonjour,
Je voudrais - si possible - éviter les clés composées.



faut savoir ce que tu veux....
les clés composés servent à accélerer les recherches multicriteres

si tu a une table avec de rubrique indexé R1 & R2
une recherche sur R1=v1 et R2=v2 introduit normalement :
acces sur index R1=v1
Parcourir tous les enregistrements, renvoyer tous les élements dont
R2=v2
d'ou les temps de recherche.....

si tu as une table avec une clé composé (R1,R2)
une recherche sur R1=v1 et R2=v2 introduit normalement :
acces sur index (R1,R2)=(v1,v2)
renvoyer les enregistrements

donc pour résumer:
si tu veux accelerer: => clé composé
(ou alors charge tout en mémoire)




Fredo MT
Le #14519871
Bonjour,
Pourquoi ne pas exécuter une requête de type HExecuteRequeteSQL avec tes
différentes conditions. Si le fait de tout charger va deux fois plus vite,
cette requête ira encore plus vite. On ne sait pas trop à vrai dire comment
Windev interprète les HFiltre sur une base MySQL en natif.

"I.G.LOG" 47fb1416$0$858$
Bonjour

J'ai une appli avec accès natif MySQL.
Sur les tables fichiers la recherche avec loupe est très longue. A titre
d'exemple, une recherche avec la loupe de la réf. "B-3339" sur un fichier
articles contenant 100.000 enreg. prend environ 15 secondes... les
utilisateurs râlent bien sur.
Le problème vient du fait que j'ai un filtre sur le fichier positionné
avec
le code suivant:

gFiltre = "IDTYPE = 4 et TERMINE = 0"
hFiltre(TABLE..FichierParcouru,TABLE..RubriqueParcourue,Caract(0),Caract(255
),gFiltre)

Ce filtre permet de sélectionner les article de type "article" (IDTYPE =
4)
toujours actifs (TERMINE = 0).
IDTYPE est indexé, TERMINE est non indexé. La rubrique de parcours
REFCONST
est indexée.

Sans le filtre, la recherche s'effectue 2 fois plus vite (ce qui n'est pas
génial non plus d'ailleurs)

Voyez vous une solution pour que la recherche soit plus rapide ?

Merci à tous




Daniel
Le #14519841
I.G.LOG a écrit :
Bonjour

J'ai une appli avec accès natif MySQL.
Sur les tables fichiers la recherche avec loupe est très longue. A titre
d'exemple, une recherche avec la loupe de la réf. "B-3339" sur un fichier
articles contenant 100.000 enreg. prend environ 15 secondes... les
utilisateurs râlent bien sur.
Le problème vient du fait que j'ai un filtre sur le fichier positionné avec
le code suivant:

gFiltre = "IDTYPE = 4 et TERMINE = 0"
hFiltre(TABLE..FichierParcouru,TABLE..RubriqueParcourue,Caract(0),Caract(255
),gFiltre)

Ce filtre permet de sélectionner les article de type "article" (IDTYPE = 4)
toujours actifs (TERMINE = 0).
IDTYPE est indexé, TERMINE est non indexé. La rubrique de parcours REFCONST
est indexée.

Sans le filtre, la recherche s'effectue 2 fois plus vite (ce qui n'est pas
génial non plus d'ailleurs)

Voyez vous une solution pour que la recherche soit plus rapide ?

Merci à tous





Ci_dessous les requêtes envoyées (j'ai viré le select) avec un
gfiltre = "SOLDE00"
HFiltre(Table..FichierParcouru,Table..RubriqueParcourue,0,500,gFiltre)


A savoir que dès que tu utilises la loupe, tu vas déclencher les 5
premières requêtes, ensuite pour chaque caractère saisit à partir du
second tu déclenches 4 requêtes.

Dans ton cas pour "B-3339", tu vas générer 5+5*4 requêtes.

C'est énorme 25 requêtes lorsque 1 seule requête suffirait.

De plus si tu es en Innodb il faut éviter de faire un count(*) et
préférer l'enregistrement du nombre d'enregistrements dans une table
séparée, sinon passer en MyIsam.

Mon conseil, éviter un maximum les automatismes à la HF et faire un
maximum de traitement à la main en SQL, pour la loupe préférer une boite
de dialogue pour déclencher la recherche


Pour les index suivre le conseil de Firetox, mais c'est loin d'être
simple, et cela dépend de l'utilisation même de ton appli.

http://dev.mysql.com/doc/refman/5.0/fr/mysql-indexes.html
http://dev.mysql.com/doc/refman/5.0/fr/join.html
http://dev.mysql.com/doc/refman/5.0/fr/explain.html



DETAIL des requêtes
////////////////////////////////////////////////////////////////////////
1/ SELECT COUNT(*) as WDACCESNATIF_NBENR FROM `lignecdes`
2/ SELECT `id`,... FROM `lignecdes` ORDER BY `commande_id`,`id`LIMIT 100
3/ SELECT COUNT(*) as WDACCESNATIF_NBENR FROM `lignecdes`
4/ SELECT COUNT(*) as WDACCESNATIF_NBENR FROM `lignecdes` WHERE (`id`<5
AND `commande_id` OR `commande_id`<18)

5/ SELECT `id`,... FROM `lignecdes` WHERE (`id`<5 AND `commande_id`
OR `commande_id`<18) ORDER BY `commande_id` DESC,`id` DESC LIMIT 100

6/ SELECT `id`,... FROM `lignecdes` WHERE `commande_id`>=0 AND
`commande_id`<P0 AND ( `lignecdes`.`SOLDE` = 1000 ) AND
`commande_id` ORDER BY `commande_id`,`id` LIMIT 100

7/ SELECT `id`,... FROM `lignecdes` WHERE `commande_id`>=0 AND
`commande_id`<P0 AND ( `lignecdes`.`SOLDE` = 1000 ) AND
`commande_id`>12 ORDER BY `commande_id`,`id` LIMIT 100

8/ SELECT `id`,... FROM `lignecdes` WHERE `commande_id`>=0 AND
`commande_id`<P0 AND ( `lignecdes`.`SOLDE` = 1000 ) AND
`commande_id` ORDER BY `commande_id` DESC,`id` DESC LIMIT 100

9/ SELECT `id`,... FROM `lignecdes` WHERE `commande_id`>=0 AND
`commande_id`<P0 AND ( `lignecdes`.`SOLDE` = 1000 ) AND
`commande_id`<12 ORDER BY `commande_id` DESC,`id` DESC LIMIT 100

10/ SELECT `id`,... FROM `lignecdes` WHERE `commande_id`>=0 AND
`commande_id` `commande_id`0 OR `commande_id`>120) ORDER BY `commande_id`,`id`
LIMIT 100

11/ SELECT `id`,... FROM `lignecdes` WHERE `commande_id`>=0 AND
`commande_id`<P0 AND ( `lignecdes`.`SOLDE` = 1000 ) AND
`commande_id`0 ORDER BY `commande_id`,`id` LIMIT 100

12/ SELECT `id`,... FROM `lignecdes` WHERE `commande_id`>=0 AND
`commande_id`<P0 AND ( `lignecdes`.`SOLDE` = 1000 ) AND
`commande_id`<120 ORDER BY `commande_id` DESC,`id` DESC LIMIT 100

13/ SELECT `id`,... FROM `lignecdes` WHERE `commande_id`>=0 AND
`commande_id` `commande_id`0 OR `commande_id`>120) ORDER BY `commande_id`,`id`
LIMIT 100




--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
I.G.LOG
Le #14519801
Bonsoir

Je viens de faire des essais de positionnement sur la table fichier
"articles" avec le code suivant

hlitrecherche(article,REFCONST,"B-3339") // Résultat instantané
TableAffiche(article,tacourantpremier) // Prend 15 secondes
!!!!

En fait, c'est le tableaffiche() qui met énormément de temps !
Et je ne connais pas d'autre focntion pour se positionner dans une table
fichier :-(
J'ai peur de devoir changer complètement de stratégie pour afficher les
articles.
A moins que vous ne voyez une solution pour afficher rapidement la table
après un positionnement "manuel" ?!

Encore merci pour vos réponses
Publicité
Poster une réponse
Anonyme