|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Migration HyperFIle vers MySQL |
| Débuté par francis.duhaut, 04 nov. 2005 10:43 - 15 réponses |
| |
| | | |
|
| |
Posté le 04 novembre 2005 - 10:43 |
Par curiosité, j'ai migré une petite application avec base HyperFile vers une base MySQL.
Je n'ai pas modifié mon code pour la gestion des données (hAjoute, hSupprime, hFiltre).
J'ai détecté une lenteur au niveau de hAjoute par rapport à HyperFIle. Je viens stocker en rafale des données provenant d'un fichier CSV et les temps sont multipliés par au moins 20 pour ces ajouts.
Dois-je impérativement intégrer du code SQL (SQL insert ....) pour ajouter des données en grosse quantité ?
Pour le reste, cela semble fonctionner sans pb.
D'avance merci. |
| |
| |
| | | |
|
| | |
| |
Posté le 04 novembre 2005 - 11:52 |
L'ideal quelque soit ta base de données est de limiter le nombre d'appelle. Si tu peux tout regrouper dans une seule requetes tu gagneras beaucoup de temps mais évidement ça demande de gerer la requete. |
| |
| |
| | | |
|
| | |
| |
Posté le 04 novembre 2005 - 12:35 |
Juste une info au passage (je me suis fait avoir...), ne pas oublier d'acheter ses licences de MySQL. On croit tous à tort qu'elles sont gratuites ! |
| |
| |
| | | |
|
| | |
| |
Posté le 04 novembre 2005 - 13:57 |
Oui....la license MySql est payante à partir du moment ou votre base de données MySql est complètement intégrée à votre appli....
Mais si vous laissez votre base de donnée 'ouverte', séparée de votre appli...en quelque sorte 'open source', cela reste gratuit.....
Mais tout le monte ne distribue pas son software en 'open source', c'est un choix... (on ne le fait pas non plus)
Fred |
| |
| |
| | | |
|
| | |
| |
Posté le 04 novembre 2005 - 14:01 |
Bonjour,
Nous avons également migré notre application en MySql, donc les Hajoute, Hmodifie,... sont également utilisés. C'est vrai que la vitesse diminue lors de traitement comme celui que tu décris mais on garde quand même cette filosophie de programmation (car ce genre de traitement est rare dans notre appli).
Cependant, toutes nos requête qui marchaient en HF ne fonctionne pas en MySql.
Peux tu me donner quelques infos (histoire de ciblé le problème chez nous)
-Version exacte de Windev
-Version exacte de MySql
-Date de ta LibMySql
-As tu des requête faisant 2 JOIN ou plus ?
Merci d'avance pour tes infos
Fred |
| |
| |
| | | |
|
| | |
| |
Posté le 04 novembre 2005 - 14:58 |
Salut,
Windev 090314j
MySQL 4.0.26
Date fichier LibMySQL.DLL -> 05/09/2005
J'utilise léditeur de requete intégré de Windev avec hExecuteRequete().
En fait j'ai un fichier CSV contenant 5000 lignes à importer.
1/ Je lis donc une ligne
2/ j'affecte les variables de la table
3/ je fais hAjoute.
Sans rien toucher, je me prends 3mn de traitement au lieu de 20 secondes en hyperfile....
Je ne vois pas d'autre solution pour aller plus vite.
Est-ce du à l'accès natif ?
Merci, |
| |
| |
| | | |
|
| | |
| |
Posté le 04 novembre 2005 - 17:00 |
5.000 lignes à importer, c'est pas la mer à boire,
moi j'ai plus d'un million de ligne, et j'ai tjs pas de solution,
donc on lance sur un pc un soir, et on espere que ça plante pas,
et on compte le nombre de jour......
des fois, je me demande si ça irai pas plus vite avec un upload de fichier
txt sur une page php
qui ferai elle meme les insert.
si vous avez es solutions, je prends sans hésiter.
cordialement
"Francis DUHAUT" <francis.duhaut@fr.enersys.com> a écrit dans le message de
news: 436b62f5$1@news.pcsoft.fr...
Salut,
Windev 090314j
MySQL 4.0.26
Date fichier LibMySQL.DLL -> 05/09/2005
J'utilise léditeur de requete intégré de Windev avec hExecuteRequete().
En fait j'ai un fichier CSV contenant 5000 lignes à importer.
1/ Je lis donc une ligne
2/ j'affecte les variables de la table
3/ je fais hAjoute.
Sans rien toucher, je me prends 3mn de traitement au lieu de 20 secondes
en hyperfile....
Je ne vois pas d'autre solution pour aller plus vite.
Est-ce du à l'accès natif ?
Merci,
|
| |
| |
| | | |
|
| | |
| |
Posté le 07 novembre 2005 - 09:01 |
Bonjour,
Merci pour tes précisions...
C'est un peu normal que le temps soit plus long (je ne dis pas que c'est bien  )...
(l'acces nativ, le INSERT de MySql,... tout cela est moins rapide que HF)
J'ai élaborer un programme pour convertir l'entiereté de notre base de donnée HF en MySql
(pour donner une idée : +- 200 fichiers, le + grand : 270 000 records)
Au début j'utilisais du Hajoute.....et c'était effectivement très long.....
Puis, j'ai converti chacun de mes fichier HF en txt et puis utilisé le
LOAD DATA IN FILE comme requête à MySql pour charger le fichier dans la table MySql
J'ai divisé le temps par 10 environ !!!!
A bon entendeur.....
Je répète ma question : TOUTES tes requêtes (faites dans l'éditeur) fonctionne une fois connectées à MySql ??? parce que certaines chez non se plantent (et après analyse du problème, c'est l'acces natif qui s'emmêle les pinceaux semble-t-il)
Salutations
Fred |
| |
| |
| | | |
|
| | |
| |
Posté le 07 novembre 2005 - 09:07 |
re-bonjour,
Je viens de remarqué que notre LibMysql à une date bien antérieure.
Est-elle liée à la version MySql car elle est plus ancienne aussi ?
Version MySql : 4.0.20a
LibMysql : 28/05/2004
Ou trouver cette LibMysql ? est-elle liée à la version de Mysql ?
Pourrait-elle être la source de certains de nos problèmes ?
Merci
Fred |
| |
| |
| | | |
|
| | |
| |
Posté le 07 novembre 2005 - 11:18 |
Pour ce qui est des problèmes de requêtes avec l'accès natif mysql...
J'ai voulu migrer une applic HF/CS en mysql...
IM-PO-SS-IB-LE
Toutes mes requêtes déclarées dans windev, comportant des jointures à la syntaxe windev plantaient, et si j'utilisais la syntaxe SQL standard, il refusait de les exécuter...
Je pense que l'accès natif mysql n'étant pas commercial, il n'a pas bénéficié de tous les soins nécessaires, enfin c'est juste mon opinion. |
| |
| |
| | | |
|
| | |
| |
Posté le 07 novembre 2005 - 11:24 |
"Francis DUHAUT" <francis.duhaut@fr.enersys.com> writes:
Par curiosité, j'ai migré une petite application avec base HyperFile
vers une base MySQL.
Je n'ai pas modifié mon code pour la gestion des données (hAjoute,
hSupprime, hFiltre).
J'ai détecté une lenteur au niveau de hAjoute par rapport à
HyperFIle. Je viens stocker en rafale des données provenant d'un
fichier CSV et les temps sont multipliés par au moins 20 pour ces
ajouts.
Dois-je impérativement intégrer du code SQL (SQL insert ....) pour
ajouter des données en grosse quantité ?
C'est préférable, car lorsque tu travailles sur des bases type MySQL,
Oracle etc... les fonctions H sont traduites en ordre SQL, donc tu
éviteras le temps de la traduction.
Ensuite viennent les mécanismes propres aux bases, dans la mesure du
possible écrire ton opération dans une seule et unique transaction, le
moteur n'aura qu'à valider la globalité au lieu de x fois
opérations.
Sur des benchmarks que j'avais fait en général HF était 2 fois plus
rapide en écriture si il n'y avait qu'un seul client, ensuite à partir
de 2 clients les autres bases en écriture étaient plus rapides. Les
tests avaient été faits en ordre H pour HF et SQL pour les autres.
Pour le reste, cela semble fonctionner sans pb.
D'avance merci.
--
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
|
| |
| |
| | | |
|
| | |
| |
Posté le 07 novembre 2005 - 13:46 |
"Stef" <guest@newsgroup.fr> writes:
Pour ce qui est des problèmes de requêtes avec l'accès natif mysql...
J'ai voulu migrer une applic HF/CS en mysql... IM-PO-SS-IB-LE
Toutes mes requêtes déclarées dans windev, comportant des jointures à
la syntaxe windev plantaient, et si j'utilisais la syntaxe SQL
standard, il refusait de les exécuter...
Je suis surpris de ces impossibilités. Pour quelques tests j'ai déjà
utilisé l'accès natif de PCsoft pour MySQL et je ne me souviens pas
avoir rencontré ce type de problème en SQL.
Je pense que l'accès natif mysql n'étant pas commercial, il n'a pas
bénéficié de tous les soins nécessaires, enfin c'est juste mon
opinion.
--
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
|
| |
| |
| | | |
|
| | |
| |
Posté le 07 novembre 2005 - 14:21 |
Etonnant....
Avais-tu des requetes paramétrées décrites en tant qu'objets windev et utilisant au moins 2 jointures? |
| |
| |
| | | |
|
| | |
| |
Posté le 07 novembre 2005 - 16:38 |
J'ai également beaucoup de problèmes dès que j'ai 2 jointures ou plus...
Je partage ton avis Jef....
Mais peut-être qu'en exposant explicitement nos problèmes ici, nous pourrions en trouver les causes et (alerter les services compétants) non ?
Exemples : créez une requête contenant au moins 2 JOIN dans votre éditeur et testez là en accès natif MySql...
Si ca fonctionne chez quelqu'un, qu'il me le signale svp, peut-être serait-ce un début de piste pour résoudre mon problème...
Merci à vous
Fred |
| |
| |
| | | |
|
| | |
| |
Posté le 07 novembre 2005 - 19:53 |
"Fred" <fred-76@hotmail.com> a écrit dans le message de
news:436f6eef$1@news.pcsoft.fr...
J'ai également beaucoup de problèmes dès que j'ai 2 jointures ou plus...
[CUT]
Des problèmes de performances ? de non exécution ?
> Exemples : créez une requête contenant au moins 2 JOIN dans votre éditeur
et testez là en accès natif MySql...
Un exemple de SQL généré (en mode concepteur) serait intéressant.
Ensuite un Explain de votre requete dans un frontal MySQL pour avoir le plan
d'accès.
Le temps d'execution de cette requete dans un frontal (après optimisation en
fonction de l'explin ci dessus).
Si le temps est plus court, trapper la requete reellement executée par
WinDev en mode test (voir si c'est le même ordre). Si c'est le même =>
remonter l'anomalie au ST 
Si ca fonctionne chez quelqu'un, qu'il me le signale svp, peut-être
serait-ce un début de piste pour résoudre mon problème...
--
Emmanuel Lecoester |
| |
| |
| | | |
|
| | |
| |
Posté le 07 novembre 2005 - 22:07 |
par exemple, si j'avais un objet windev "req_machin" avec un contenu comme
SELECT
fichier1.zone1,
fichier2.zone2,
fichier3.zone3
FROM fichier1 LEFT JOIN fichier2 ON (...),
fichier2 LEFT JOIN fichier3 ON (...)
WHERE fichier1.critere = {_xxxx}
Ayant utilisé l'option "taper le code sql" (je supporte pas l'assistant requete de wndev).
lors de l'exécution je fais un
req_machin._xxxxx = "trucmuche"
hexecuterequete(req_machin)
La, hexecuterequeteme retourne une erreur de syntaxe dans la clause FROM, la syntaxe SQL correcte serait
SELECT
fichier1.zone1,
fichier2.zone2,
fichier3.zone3
FROM fichier1 LEFT JOIN fichier2 ON (...),
LEFT JOIN fichier3 ON (...)
WHERE fichier1.critere = {_xxxx}
c'est a dire sans indiquer le fichier a gauche du 2e "LEFT JOIN"
le problème c'est que si je met ca à la bonne syntaxe, la requete est considérée comme fausse par l'éditeur de code et c'est impossible de la travailler ou de renseigner le parametre _xxxxx dans un traitement.
Si on exécute en mode "sanscorrection", ben ca change rien à ce problème de manipulation.
J'ai écrit au support technique a ce sujet, il m ont répondu d'utiliser le mode sanscorrection mais comme je le dis plus haut : ca résout rien.
La solution à ce moment là c'est de décrire ses requetes au format chaine et employer hexecuterequeteSql mais on perd toute la sympathie de l'intellisense et la possibilité de liaison avec une table de données. |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|