Discussion :

[yann_72]

Bonjour,

Je suis très surpris de voir la différence de vitesse dans les traitements pour attaquer une base Mysql à partir de windev:

La façon suivante:

Code :

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

1
2
3
4
5
 
SQLConnect(.............MaBaseMySQL......)
SQLExec("SELECT * FROM MaTable,"REQ1")
SQLPremier("REQ1")
TOTO = SQLCol("REQ1",1)

Est beaucoup plus rapide que d'importer la structure des tables MySql dans l'analyse Windev et d'utiliser ensuite:

Code :

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

1
2
3
 
HlitPremier(MaTable)
TOTO =MaTable.Nom

Dans le 2ème cas, il y a moins de code à taper et j'avoue que c'est plus confortable de travailler comme ça. Hélas, le temps de traitement est plus long!

(Mon appli a pour but de transferer les données provenant d'un fichier xml vers une base MySql)

avez-vous des avis sur cette différence de temps???

[vmolines]

Il parait qu'il faut ajouter hSansRafraichir lors de l'utilisation de HLitPremier. Ceci aurait pour effet de ne pas réexecuter la requête et d'économiser du temps.

Testez et donnez le résultat, ça peut être intéressant.

[yann_72]

Ah ouai ??

Et bien je m'en vais tester ça de suite......

[Gilles_69]

Salut,
ce test m'a intrigué et donc j'ai fait un essai. Le résultat est éloquent. A partir de WD12 (désolé) voici les résultats :
- table MySQL de 435000 enreg.
- parcours simple comme décrit dans le post, avec une petite somme sur un champ numérique au passage.
- même interface graphique
- tests effectués 5 fois pour relever des valeurs moyennes
Résultats :
Avec hLitxxx -> 27 s
Avec SQLxxx -> 5 s
Le confort a un prix !!!

[vmolines]

Pour les ordres H* tu as essayé avec le fameux hSansRafraichir ?

Je ne l'ai pas testé moi même car je n'ai pas de projet avec des ordres H sous la main. C'est quelquechose que j'ai entendu souvent mais sans jamais avoir de tests pour confirmer quels sont les gains, c'est pour ça que j'aimerais bien savoir.

[yann_72]

merci pour ce test qui vient conforter mon idée.

Imagine la différence de temps lorsqu'il s'agit d'effectuer de gros traitements...

Je n'en reviens pas et surtout je ne comprends pas!


Sinon je n'ai pas essayer le "Hsansrafraichir" pour la bonne raison que je fais uniquement de l'ajout car je pars d'une base MySql vide, et je n'ai pas besoin de la parcourir... dslé

[Gilles_69]

Je viens d'essayer l'ajout de Hsansrafraichir sous la forme suivante :
HLitPremier(tblheures,"",hSansRafraîchir)
et aucune amélioration.

A+

[vmolines]

Moi les ordres H*, j'ai vite arrêté. Le confort que ça offre est à mes yeux très relatif et masque trop souvent des choses qui peuvent s'avérer gênantes car non maîtrisées.

J'utilise exclusivement des requêtes via les ordres SQL. Pour alléger le côté lourd du nom de requête à passer aux ordres SQL, j'ai encapsulé ça dans une classe cRequête qui génère et réutilise automatiquement un nom de requête. Ainsi pas d'erreur d'étourderie possible car j'ai la sécurité du nom de l'objet que je manipule.

D'autres procédures peuvent être vite écrites lorsqu'on réutilise toujours les même lignes de code et effacer le côté "barbare" des ordres SQL.

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
sSql est une chaîne = [
SELECT     
	T_Facture.ID_Facture, 
	T_Facture.Avoir, 
	T_Facture.Date_Facture, 
	T_Facture.Num_Client, 
	T_Facture.Nom_Client, 
	T_Facture.BordereauOk,
	SUM(T_LigneFacture.Prix_Unitaire_HT * T_LigneFacture.Quantite) as MontantHT, 
	SUM( (1 + T_LigneFacture.Taux_TVA) * T_LigneFacture.Prix_Unitaire_HT * T_LigneFacture.Quantite) as MontantTTC, 
	T_Facture.ExportComptaOK
FROM T_Facture       
 
	INNER JOIN T_LigneFacture 
		ON T_Facture.ID_Facture = T_LigneFacture.ID_Facture
 
	LEFT JOIN T_LotActivite 
		ON T_LotActivite.ID_LotActivite = T_Facture.ID_LotActivite
 
		LEFT JOIN T_Escale
			 ON T_Escale.ID_Escale = T_LotActivite.ID_Escale 
 
GROUP BY 	T_Facture.ID_Facture, T_Facture.Avoir, T_Facture.Date_Facture, T_Facture.Num_Client, T_Facture.Nom_Client, T_Facture.BordereauOk, T_LotActivite.ID_LotActivite, T_Escale.ID_Escale, T_Facture.ID_Client, T_Facture.ExportComptaOK 
ORDER BY T_Facture.Date_Facture DESC
]
 
oReqFacture est une cRequete
 
oReqFacture:Executer(sSql)
oReqFacture:Premier()
TANTQUE PAS oReqFacture:EnDehors()
 
	...
 
	oReqFacture:Suivant()
FIN

De plus les SQLFerme() sont automatiquement effectués à la destruction de mes objets cRequete

[yann_72]

Bon bha comme ça au moins c'est clair!

je sais ce qu'il me reste à faire.......

merci

[Gilles_69]

Je suis d'accord, la seule chose c'est que les ordres SQLLitCol retournent des chaines et qu'il faut dans le cas de manipulation de numériques penser à utiliser la conversion val(SQLLitCol("REQ1",1) par exemple.

A+

[vmolines]

Oui, en effet, c'est un travail supplémentaire. C'est bien de le préciser.

Il y a aussi le travail sur les chaines passées dans les requêtes : échapper les caractères spéciaux, quoter les chaines, ...

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
		sSql = [
		INSERT INTO T_Activite (ID_DetailPrestation, 	Quantite, ID_LotActivite, DateHeure_Debut, DateHeure_Fin, ID_Marchandise, ID_Ressource, Prix_Unitaire, Observation) 
		VALUES (%1, %2, %3, %4, %5, %6, %7, %8, %9)
		]
 
		sSql = ChaîneConstruit(sSql, 	pnIdDetailPrestation, ...
						txtQuantite, ...
						pnIdLotActivite, ...
						cConnexionSQLServer::FormatDate(txtDateDebut), ...
						cConnexionSQLServer::FormatDate(txtDateFin), ...
						cboMarchandise, ...
						cboRessource, ...
						0, ...
						cConnexionSQLServer::FormatChaine(txtObservations))		
 
		SI oReq:Executer(sSql) ALORS
			znRetour = oReq:LastId()
		FIN

[Louis Griffont]

Personnellement, j'ai adopté SQLManagerX et je ne regrette pas !

[vmolines]

J'ai parcouru SQLManagerX le site plusieurs fois mais n'ai pas eu l'occasion de tester. Ca mérite de s'y pencher en tout cas. J'espère un jour avoir la possibilité et le temps de le faire.

[Louis Griffont]

Perso, je ne regrette pas.

Avec la même appli, je peux attaquer une base MySQL, Acces, PostGreSQL, Oracle, SQLite, MSSQL en ne changeant qu'une ligne de code (voire même en le paramètrant !)

[vmolines]

Perso, je ne regrette pas.

Avec la même appli, je peux attaquer une base MySQL, Acces, PostGreSQL, Oracle, SQLite, MSSQL en ne changeant qu'une ligne de code (voire même en le paramètrant !)

L'intérêt par rapport à la portabilité, je serais beaucoup plus méfiant. Je ne crois pas encore que ce soit possible d'avoir du SQL multibase car j'écris encore très souvent des requêtes avec des spécificités propres à chaque SGBD. De plus, si certaines conversions sont simples (un nom de fonction qui change par exemple), certaines notions ne sont pas du tout portables ou la réécriture est totalement différente.

[Emmanuel Lecoester]

L'intérêt par rapport à la portabilité, je serais beaucoup plus méfiant. Je ne crois pas encore que ce soit possible d'avoir du SQL multibase car j'écris encore très souvent des requêtes avec des spécificités propres à chaque SGBD. De plus, si certaines conversions sont simples (un nom de fonction qui change par exemple), certaines notions ne sont pas du tout portables ou la réécriture est totalement différente.

Exact mais du mode monotable c'est des ordres standards. Ensuite pour les trancodification au lieu de faire le substr dans la requete tu le fais dans WinDev.

PC-SOft avec ses accès natifs se frote au même problème.

[vmolines]

Oui je suis tout à fait d'accord pour dire que les requêtes simples sont parfaitement portables automatiquement via les outils dont on parle.

Effectivement les accès natifs et l'éditeur de requêtes windev sont confrontés au même problème. C'est pour ces restrictions que je ne les utilises pas.

Je pense que le jour où j'aurais un projet multibases à faire, je ferais une classe dans laquelle chaque requête sera définie et testée manuellement pour chaque SGBD cible. A l'execution le programme utilisera l'ordre SQL spécifique en fonction de la connexion en présence.

Heureusement, je n'ai rien de prévu qui concerne le multibase

[Louis Griffont]

Tout dépend comment tu gères ton SGBD par rapport à ton programme !

Moi je suis du genre à tout faire dans le programme, et ne me servir du serveur de données, que comme... serveur de données (pas de procédure stockée, ...)