Waouh
La première chose à vérifier est que si tu as plusieurs filtres dans la même table de données, tu doit y mettre une index.
Exemple pour une table de Items
Si dans le WHERE de ta requête tu as par exemple :
Ta table de données devrait contenir un Index sur IdItemsType + IdCouleurCode (Windev):SELECT *
FROM Items
WHERE
Items.IdItemsType = 1
and Items.IdCouleur = {pIdCouleur}
Alors lors de ta requête, plutôt que de filtrer sur IdItemsType et ENSUITE filtrer sur IdCouleur, la requête filtrera une fois sur ton index (windev appel ca une clé-composé).
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
Essaie aussi de mettre tes rubriques que tu mets dans ton WHERE en clé avec doublons. Ceci accélérera beaucoup les recherches car ton serveur à déjà sa "position" dans le fichier de données. (S'il sont en clé-composé, pas besoin de les mettre en clé avec doublons)
De ce que j'ai vu, l'optimiseur de requête te disait pas mal de faire ca, donc pas réellement besoin de lui pour le savoir
Sinon, tu peux lancer ta requête à partir du centre de contrôle HFSQL et valider les temps que ta requête utilise.
Et aussi consulte le EXPLAIN dans le centre de contrôle pour voir sur quel clé ta requête filtre.
Ensuite, essaie de préféré une requête qui te renvoie seulement les données voulues plutôt que de faire un SELECT *
Plus il y a de données retournée inutilement, plus tu perd du temps inutilement.
Espérant t'avoir éclairer un peuCliquez pour agrandir...
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
merci
à ma connaissance la requête stockée (en elle même) ne s'exécutera pas plus vite qu'une requête lancée depuis ton poste. Par contre, un des avantages est que si tu as plusieurs application qui utilise la même analyse, ta requête devient utilisable dans toute tes applications.
Pour ce qui est de la procédure stockée, elle sera exécutée entièrement sur le serveur. Par contre tu n'as pas accès au requête standard de ton application, mais seulement au requête stockée, donc c'est la que les requêtes stockées entrent en jeu le plus souvent à mon avis.
L'avantage d'une procédure stockée est que, tu l'appel de ton application, le serveur exécute TOUT le travail et ENSUITE te renvoie le résultat.
Si par exemple tu veux faire une mise à jours de la quantité de ton stock pour tout tes items.
La première chose à ce qu'on pense est de faire un
En réalité, ton POUR TOUT enverra une demande de modification pour chaque item vers ton serveur.Code (Text):POUR TOUT Items
Items.QtéStock = NouvelleQté
HModifie(Items)
FIN
Si tu as 25 000 items, ça fait 25 000 demandes de modification donc 25 000 va et vient sur le réseau.
Ce qui se passe en réalité, c'est que ta demande de modification est faite au serveur et ton HModifie attend la réponse du serveur avant de continuer (il te renvoie vrai ou faux) ensuite il passe au prochain enregistrement.
Si ton serveur est à distance et que tu as ne serais-ce que 5ms de latence, imagine la longueur du traitement :
5ms pour effectuer la demande >>> traitement sur serveur >>> 5ms pour recevoir la demande
Ça vient de prendre plus de 4 minutes pour exécuter ta mise à jour de 25000 données. (un serveur local va avoir moins de 5ms de latence bien sur, mais bon, c'est pour l'exemple)
Par contre si tu exécute une procédure stockée, tu peux faire ton POUR TOUT directement sur le serveur, tu sauve toute la latence et le transfert sur ton réseau car tu n'as que UNE demande au serveur et UN retour vers ton poste. Le traitement ne va prendre que 3-4 secondes.
Un autre avantage aussi de la procédure stockée c'est qu'elle est modifiée en "live". Si tu modifie son code, tu exécute la génération de l'analyse et c'est déjà en place sur le serveur et c'est pris en compte sur le chant.
Par contre modification à une procédure de ton application va nécessité soit un patch, soit une mise à jours de ton appli.
En bref, si tu as plusieurs application qui utilise la même analyse, privilégie les procédure et requête stockée pour la ré-utilisabilité.
Pour tout traitement avec beaucoup de va et vient, les procédures stockées seront ton amie.
Gemini1961 et Man aiment ça.
Pour ce qui est des requêtes entre plusieurs table, la liaison fait déjà le travail, tu ne peux pas être plus rapide que ça (selon mes connaissances)
Clé unique vers clé avec doublons, c'est pas mal ça
Si quelqu'un à d'autre suggestions, je suis preneur
Un autre conseil est bien évidement le nombre de données dans tes tables, tu peux faire un fichier historique pour ne garder que les données dont tu as de besoins. Et seulement si tu as de besoins de chercher dans des vieilles donnés, alors là tu passe dans ta table historique. (C'est quand même plus complexe à gérer, mais c'est un autre moyen d'accéléré les recherche) Évidemment, je te dirais que c'est en dernier recours, j'ai plusieurs centaines de milliers de lignes dans certaines BD et je n'ai pas encore sentie le besoin de créer des tables "historiques". Si tes clés sont bien définie, le serveur n'aura pas à parcourir les enregistrements.
Il y a aussi les vues qui sont en quelque sorte le résultat d'une requête donnée. J'en ai jamais réellement fait (peut-être je devrais mais bon... pour l'instant j'en ai pas sentie le besoin). Alors je ne peux pas vraiment t'aider sur ce sujet.
Et pour finir, tu peux utiliser le centre de contrôle pour optimiser et recalculé les index. Ceci permet au serveur de mettre en cache les meilleurs "chemins" pour récupéré les données si on peut dire selon les demandes qui lui ont été faite. (si j'ai bien compris)
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
Man apprécie ceci.
Pour ce qui est des requêtes entre plusieurs table, la liaison fait déjà le travail, tu ne peux pas être plus rapide que ça (selon mes connaissances)
Clé unique vers clé avec doublons, c'est pas mal ça
Si quelqu'un à d'autre suggestions, je suis preneur
Un autre conseil est bien évidement le nombre de données dans tes tables, tu peux faire un fichier historique pour ne garder que les données dont tu as de besoins. Et seulement si tu as de besoins de chercher dans des vieilles donnés, alors là tu passe dans ta table historique. (C'est quand même plus complexe à gérer, mais c'est un autre moyen d'accéléré les recherche) Évidemment, je te dirais que c'est en dernier recours, j'ai plusieurs centaines de milliers de lignes dans certaines BD et je n'ai pas encore sentie le besoin de créer des tables "historiques". Si tes clés sont bien définie, le serveur n'aura pas à parcourir les enregistrements.
Il y a aussi les vues qui sont en quelque sorte le résultat d'une requête donnée. J'en ai jamais réellement fait (peut-être je devrais mais bon... pour l'instant j'en ai pas sentie le besoin). Alors je ne peux pas vraiment t'aider sur ce sujet.
Et pour finir, tu peux utiliser le centre de contrôle pour optimiser et recalculé les index. Ceci permet au serveur de mettre en cache les meilleurs "chemins" pour récupéré les données si on peut dire selon les demandes qui lui ont été faite. (si j'ai bien compris)
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
Cliquez pour agrandir...
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
j'apprécie difficile quelqu'un mais tu en es une espèce à qui je dois respect car tu viens de me faire un cours et si peu j'ai compris.Et je me résume
pour résoudre mon problème de lenteur d'accès aux données à distance je dois utiliser des procédures et requêtes stockées qui me faciliteront les allers-retours entre le client et le serveurs.
Pensez à utiliser le centre de co,ntrôle pour optimiser et réparer les fichiers HFSQL
Mais un des membres m'a suggéré d'utiliser les Webservices il m'a même donné une vidéo pour m’imprégner. Là je t'avoue que je n'ai rien pigé du coup je vois en ça mon calvaire et pourtant ces webservices doivent être mon quotidien car ils permettent d'améliorer la vitesse entre le client et le serveur.
As-tu une idée dessus ?
Si oui je souhaiterais que tu partages avec moi ton expérience avec quelques pratiques des bouts de codes, si c'est possible je peux t'envoyer mon projet d'entraînement pour y jeter un coup d'oeil.
Merci d'avance et Bonjour !
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
Ca me fait grandement plaisir de savoir que j'ai pu t'éclairer et merci beaucoup pour ton appréciation
Je suis quelqu'un qui aime comprendre les choses alors j'essaie d'expliquer le pourquoi plutôt que le comment.
Donne un poisson à un homme, et il mangera un jour. Apprend lui à pêcher et il mangera toujours...
Malheureusement, pour ce qui est des webservice j'ai pas touché pour l'instant, alors je ne pourrais pas t'aider là-dessus. De ce que j'ai compris, les données envoyer via un webservice son plus "light" que ce qu'envoie le serveur. Donc plus rapide, plus facile à sécurisé car tes données ne sont pas manipuler par l'application mais c'est le webservice qui accède au donnée et te renvoie le résultat voulue. A part de ca, je ne m'y connais pas assez pour t'aider.
Pour ce qui est de ton problème de lenteur d'accès distant, si tes données passe par internet, assure toi d'avoir un upload assez puissant, souvent les connexions on un faible taux d'upload (entk au québec) et surtout un bon ping. Valide aussi que tes .FIC, .MMO ne passe pas par l'anti-virus.
En accès distant, assure toi de toujours récupérer tes données via une requête et n'affiche jamais de table avec accès en direct, sinon tu vas avoir des va et vient constant.
Pour ma part, je travail beaucoup avec une requête, stock le résultat dans un tableau de structure et / ou associatif et ensuite je travail avec les données en mémoire de mon tableau.
Tu peux utiliser le HSurveilleBonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
pour récupéré SEULEMENT les données modifié et mettre à jours ton tableau.
C'est plus long à programmer, mais je vois beaucoup de gain en performance.
Prenons par exemple une application qui prend des commandes.
Ta liste de produits et ta liste de clients ne devrait pas changer à chaque seconde... Tu peux donc les charger en mémoire. Tu n'auras plus à aller chercher ta liste client et ta liste produit sur le serveur.
Tu te créer une fonction qui valide si ton tableau de client en mémoire est vide, si oui, tu récupère, si non tu lit dans ton tableau mémoire.
Code (Windev):
A chaque ouverture de fenêtre qui doit avoir accès au client, tu lance ta procédure _ValideSiListeClientVide. La première fenêtre qui accédera au client sera lente à charger, mais les autres seront hyper rapide car il récupèrera les données préchargé et ne relancera pas de requête.
Il ne te reste alors que les données qui change souvent à lancer des requêtes régulièrement.
Si tu as des recherches, l'accès mémoire est beaucoup plus rapide que de relancer une requête, tu peux facilement filtré tes données. Quand je doit affiché plusieurs données, exemple que je veux affiché la liste de tout met client dans une table. Je créer souvent 2 tableaux, exemple, tListeClient et tListeClientFiltrer, je met ma liaison fichier de ma table sur le tableau tListeClientFiltrer. Dans ma zone de recherche je met un bout de code du genre. (Il y a peut-être mieux comme méthode, mais je trouve que ca va bien et les performances sont très bonne, juste plus long à coder que de faire un TableAffiche(Table_Client, taréexécuterequête))
Code (Text):r est une chaine = SAI_Recherche
d est une chaine // récupère les données du client en cours
// Supprime le tableau filtré
tListeClientFiltre.SupprimeTout
// si la zone de recherche est vide, on affiche tout les clients, donc mon filtre = tout mes clients
Si r ~= "" alors
tListeClientFiltre = tListeClient
SINON
POUR TOUT c de tListeClient
// on passe les données qu'on veut recherche à notre chaine
d = tListeClient.Nom + " " + tListeClient.NumTel + " " + tListeClient.AutreRubriqueVoulueDansMaRecherche
// si Contient renvoie vrai alors il y a une concordence on ajoute le client à notre tableau filtré
Si Contient(d, r, sanscasse) alors
tListeClientFiltre.Ajoute(c)
FIN
FIN
// Dans tout les cas on réaffiche la table
Table_Client.Affiche()
Tu peux aussi faire unBonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
pour savoir si ta ou tes tables de données que ta requête à de besoin à/ont été modifié, sinon, c'est inutile de relancer une requête si rien n'a changé.
Pour ce qui est du partage de ton projet, je manque déjà beaucoup de temps pour mes projets alors, je ne pourrais malheureusement pas m'impliquer.
Espérant t'avoir mit sur certaines pistes pour t'aider à continuer à avancer
PS, les codes on été écrit à la volé alors s'il y a des erreurs de compilation, ne m'en veux pas
Fouedusa, Solowdiom, Man et 5 autres personnes aiment ça.
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
Ca me fait grandement plaisir de savoir que j'ai pu t'éclairer et merci beaucoup pour ton appréciation
Je suis quelqu'un qui aime comprendre les choses alors j'essaie d'expliquer le pourquoi plutôt que le comment.
Donne un poisson à un homme, et il mangera un jour. Apprend lui à pêcher et il mangera toujours...
Malheureusement, pour ce qui est des webservice j'ai pas touché pour l'instant, alors je ne pourrais pas t'aider là-dessus. De ce que j'ai compris, les données envoyer via un webservice son plus "light" que ce qu'envoie le serveur. Donc plus rapide, plus facile à sécurisé car tes données ne sont pas manipuler par l'application mais c'est le webservice qui accède au donnée et te renvoie le résultat voulue. A part de ca, je ne m'y connais pas assez pour t'aider.
Pour ce qui est de ton problème de lenteur d'accès distant, si tes données passe par internet, assure toi d'avoir un upload assez puissant, souvent les connexions on un faible taux d'upload (entk au québec) et surtout un bon ping. Valide aussi que tes .FIC, .MMO ne passe pas par l'anti-virus.
En accès distant, assure toi de toujours récupérer tes données via une requête et n'affiche jamais de table avec accès en direct, sinon tu vas avoir des va et vient constant.
Pour ma part, je travail beaucoup avec une requête, stock le résultat dans un tableau de structure et / ou associatif et ensuite je travail avec les données en mémoire de mon tableau.
Tu peux utiliser le HSurveilleBonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
pour récupéré SEULEMENT les données modifié et mettre à jours ton tableau.
C'est plus long à programmer, mais je vois beaucoup de gain en performance.
Prenons par exemple une application qui prend des commandes.
Ta liste de produits et ta liste de clients ne devrait pas changer à chaque seconde... Tu peux donc les charger en mémoire. Tu n'auras plus à aller chercher ta liste client et ta liste produit sur le serveur.
Tu te créer une fonction qui valide si ton tableau de client en mémoire est vide, si oui, tu récupère, si non tu lit dans ton tableau mémoire.
Code (Windev):
A chaque ouverture de fenêtre qui doit avoir accès au client, tu lance ta procédure _ValideSiListeClientVide. La première fenêtre qui accédera au client sera lente à charger, mais les autres seront hyper rapide car il récupèrera les données préchargé et ne relancera pas de requête.
Il ne te reste alors que les données qui change souvent à lancer des requêtes régulièrement.
Si tu as des recherches, l'accès mémoire est beaucoup plus rapide que de relancer une requête, tu peux facilement filtré tes données. Quand je doit affiché plusieurs données, exemple que je veux affiché la liste de tout met client dans une table. Je créer souvent 2 tableaux, exemple, tListeClient et tListeClientFiltrer, je met ma liaison fichier de ma table sur le tableau tListeClientFiltrer. Dans ma zone de recherche je met un bout de code du genre. (Il y a peut-être mieux comme méthode, mais je trouve que ca va bien et les performances sont très bonne, juste plus long à coder que de faire un TableAffiche(Table_Client, taréexécuterequête)
Code (Text):r est une chaine = SAI_Recherche
d est une chaine // récupère les données du client en cours
// Supprime le tableau filtré
tListeClientFiltre.SupprimeTout
// si la zone de recherche est vide, on affiche tout les clients, donc mon filtre = tout mes clients
Si r ~= "" alors
tListeClientFiltre = tListeClient
SINON
POUR TOUT c de tListeClient
// on passe les données qu'on veut recherche à notre chaine
d = tListeClient.Nom + " " + tListeClient.NumTel + " " + tListeClient.AutreRubriqueVoulueDansMaRecherche
// si Contient renvoie vrai alors il y a une concordence on ajoute le client à notre tableau filtré
Si Contient(d, r, sanscasse) alors
tListeClientFiltre.Ajoute(c)
FIN
FIN
// Dans tout les cas on réaffiche la table
Table_Client.Affiche()
Tu peux aussi faire unBonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
pour savoir si ta ou tes tables de données que ta requête à de besoin à/ont été modifié, sinon, c'est inutile de relancer une requête si rien n'a changé.
Pour ce qui est du partage de ton projet, je manque déjà beaucoup de temps pour mes projets alors, je ne pourrais malheureusement pas m'impliquer.
Espérant t'avoir mit sur certaines pistes pour t'aider à continuer à avancer
PS, les codes on été écrit à la volé alors s'il y a des erreurs de compilation, ne m'en veux pasCliquez pour agrandir...