|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Table et Vitesses catastrophiques |
| Débuté par kerloic.armor, 19 jan. 2005 16:25 - 6 réponses |
| |
| | | |
|
| |
| Posté le 19 janvier 2005 - 16:25 |
Bonjour.
Je suis en train d'évaluer Windev 8 pour une migration d'un produit VB commercial, qui utilise beaucoup des grilles (équivalent des tables.)
gros problème: en Windev, les temps de réponses sont CATASTROPHIQUES dès que la table montre des données provenant de requêtes un peu complexes. Par exemple, trois fichiers, reliées par des jointures externes...
Ma question est la suivante:
Est-ce raisonnable d'utiliser des tables basés sur des requêtes?
Merci. |
| |
| |
| | | |
|
| | |
| |
| Posté le 19 janvier 2005 - 16:52 |
Bonjour
Avez-vous défini des clés d'accès sur vos fichiers?
Exemple:
Le fichierA est lié au fichierB par la zone IDFichierA (la jointure).
Il faut une clé dans le fichierA sur la zone IDFichierA et une clé dans le fichierB sur la zone IDFichierA.
Cela devrait améliorer les performances.
Cordialement |
| |
| |
| | | |
|
| | |
| |
| Posté le 19 janvier 2005 - 17:51 |
| Devrait être rapide; vérifier au moins les paramètres de rafraichissement (ne pas demander de rafraichissement) , la validité des clés composées (utiliser le vérificateur de clé) |
| |
| |
| | | |
|
| | |
| |
| Posté le 19 janvier 2005 - 17:56 |
J'avais une clef juste d'un coté.
Oui, effectivement cela améliore beaucoup les performances.
Cela tient aussi la mer avec un ordre HExécuteRequêteSQL qui vient lire le SQL de la query.
Il me reste à essayer avec plus de 3 fichiers connectés.
Mon appli VB utilise une grille avec recherche sur chaque colonne, avec une analyse des recherches demandées pour générer le SQL de recherche, dynamiquement (parsing).
Le sql est une propriété de la Grille.
Je redéveloppe cette "grille intelligente" en Windev. Cela commence à bien fonctionner, mais les SQL que je passe peuvent être assez gros et goinfres.
Si d'autres personnes ont rencontrés des problèmes de lenteurs sur du SQL, je serais intéressés à avoir leurs commentaires.
kerloic.armor@sympatico.ca
Merci. |
| |
| |
| | | |
|
| | |
| |
| Posté le 19 janvier 2005 - 21:00 |
Effectivement, il faut bien penser a exécuter l'optimiseur de requête qui
calcul seul les clés nécessaires utiles pour accélérer les requêtes.
Antoine
Michel Lahellec wrote:
Bonjour.
Je suis en train d'évaluer Windev 8 pour une migration d'un produit
VB commercial, qui utilise beaucoup des grilles (équivalent des
tables.)
gros problème: en Windev, les temps de réponses sont CATASTROPHIQUES
dès que la table montre des données provenant de requêtes un peu
complexes. Par exemple, trois fichiers, reliées par des jointures
externes... Ma question est la suivante:
Est-ce raisonnable d'utiliser des tables basés sur des requêtes?
Merci. |
| |
| |
| | | |
|
| | |
| |
| Posté le 19 janvier 2005 - 22:30 |
Bonjour
Pour des recherches sur chaque colonne, il faut utiliser une table mémoire. Chaque colonne sera triable (en cliquant sur l'en-tête de colonne), avec recherche (en cliquant sur la loupe à droite de l'en-tête de colonne). Rien à faire en code (tout l'intérêt d'un L5G)
Ces tris et recherches se font sur les données de la table et ne demandent plus d'accès aux fichiers (allègement des charges réseau et serveurs). C'est très rapide (ça n'utilsie que le processeur du PC et la mémoire vive).
Par contre la table doit-être remplie par programmation (il n'y a plus de liaison avec un fichier ou une requête).
Si vous utlisez HExecuteRequeteSQL(...), faites après un FichierVersTable(...). Et vous pouvez libérer la ressource "source de donnée" tout de suite après (les données sont dans la table), à moins d'un besoin autre.
Cordialement |
| |
| |
| | | |
|
| | |
| |
| Posté le 19 janvier 2005 - 23:04 |
WDoptimisateur devrait deja placé des index... ca booste bien, sinon regarde l'éventualité d'attaquer un sgbdr... par odbc par exemble... les hyperfiles sont bien pratique, mais ils ne peuvent quand meme pas fournir la performance d'un sgbd.. dans tes requetes sql, prend bien que les données qui te sont utiles, évite une select * pour récupérer une seule colonne.... dans le cas de multiple requête, pense a vite faire des jointures... enfin tu trouveras des règles d'optimisation de requêtes assez facilement... si tu as dejà un parseur, ca va etre possible  |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|