Une petit réflexion sur les parcours de grosses bases de données. Chez un des mes clients qui possède un fichier CLIENT de presque 1 millions d'enregistrement, on constatais de sérieux ralentissement dans la fenêtre de recherche ... Le parcours selon le code suivant prenait environ 60 secondes : Code (Text): NomStructure est une chaîne HLitPremier(Client,Nom) TANTQUE PAS HEnDehors(Client) NomStructure = "" HLitRecherche(STRUCTURE_ACCUEIL,IDSTRUCTURE_ACCUEIL,Client.IDSTRUCTURE_ACCUEIL) SI HTrouve(STRUCTURE_ACCUEIL) ALORS NomStructure = STRUCTURE_ACCUEIL.Nom TableAjoute(TABLE_CLIENT,Client.Nom+TAB+Client.Prénom+TAB+NomStructure) HLitSuivant(Client,Nom) FIN Après optimisation, on constatait que beaucoup de client avait la même "structure" (fichier complémentaire) et que l'on relisait le fichier à chaque client... Avec ce système, on ne relit que les structures pas encore lues, donc moins de requêtes réseau et le traitement est passé à 10 secondes... Code (Text): NomStructures est un tableau associatif de chaîne HLitPremier(Client,Nom) TANTQUE PAS HEnDehors(Client) // Astuce : on ne lit le fichier STRUCTURE que s'il n'a jamais été lu. SI SansEspace(NomStructures[Client.IDSTRUCTURE_ACCUEIL]) = "" ALORS HLitRecherche(STRUCTURE_ACCUEIL,IDSTRUCTURE_ACCUEIL,Client.IDSTRUCTURE_ACCUEIL) SI HTrouve(STRUCTURE_ACCUEIL) ALORS NomStructures[Client.IDSTRUCTURE_ACCUEIL] = STRUCTURE_ACCUEIL.Nom FIN TableAjoute(TABLE_CLIENT,Client.Nom+TAB+Client.Prénom+TAB+NomStructures[Client.IDSTRUCTURE_ACCUEIL]) HLitSuivant(Client,Nom) FIN Puis nous avons ensuite tester les requêtes SQL et le traitement est passé à ... 2 secondes Code (Text): RQ_CLIENT est une Source de Données sTxtRequete est une chaîne sTxtRequete = "SELECT STRUCTURE_ACCUEIL.Nom AS NomStruc, Nom,Prenom,IDSTRUCTURE_ACCUEIL FROM CLIENT INNER JOIN STRUCTURE_ACCUEIL ON STRUCTURE_ACCUEIL.IDSTRUCTURE_ACCUEIL = CLIENT.IDSTRUCTURE_ACCUEIL " SI PAS HExécuteRequêteSQL(RQ_CLIENT,sTxtRequete) ALORS Erreur(sTxtRequete+RC+HErreurInfo()) SINON HLitPremier(RQ_CLIENT) TANTQUE PAS HEnDehors(RQ_CLIENT) TableAjoute(FEN_Table_Client,RQ_CLIENT.Nom+TAB+RQ_CLIENT.Prénom+TAB+RQ_CLIENT.NomStruc) HLitSuivant(RQ_CLIENT) FIN HAnnuleDéclaration(RQ_CLIENT) FIN MORALITE : L'abus de SQL est bon pour la santé de votre logiciel.
ThankS @Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens! :lol: Il ne manque plu que le détecteur de radar si ça va trop vite
merci gapplicat. juste une question, quel est le rôle de la fonction HAnnuleDéclaration ? est-ce qu'il est nécessaire de l'utiliser ?
Cette fonction libère de la mémoire, sur les grosses requêtes cela fait une différence importante de mémoire vive libérée... Source : Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
Autre technique : Stocker le fichier STRUCTURE ACCUEIL dans un tableau reprenant ses champs comme structure (windev) Ensuite parcourir ton fichier client et au lieu de faire : Code (Text): HLitRecherche(STRUCTURE_ACCUEIL,IDSTRUCTURE_ACCUEIL,Client.IDSTRUCTURE_ACCUEIL) Tu fais un Tableaucherche Cette technique n'est pas plus rapide que le langage SQL et une jointure mais elle fonctionne.
Oui j'y avait pensé, mais stocker un miliion d'enregistrement STRUCTURE_ACCUEIL dans un tableau cela prends trop de temps... Mais en règle générale ton idée est bonne...
Effectivement stocker autant de données devient lourd avec un tableau. Il vaut mieux conserver les jointures.
Conseils très importants : Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
Bonsoir , effectivement les requêtes sql sont largement plus rapide que les fonctions h... hlit , hlitrecherche etc... , je débug de temps en temps avec des bases de données sur un serveur distant pour voir quelles sont les endroits de mon logiciel qui sont lent , et je fait des requêtes sql pour les accélérer sinon je code au plus facile ...
Quand un projet dépasse le million d'enregistrement, il faut oublier de HFSQLCS si tu veux un rendement optimale au niveau du temps de réponse des requête.
ET tu le remplace par quoi ? J'ai un client qui dépassent le million d'enregistrement et lesd performances sont correctes, il suffit de bien optimiser les clés/requetes
SQL Server tout simplement. Le rendement d'une base SQL Server sera toujours, de mon experience, meilleur que celle du HFSQLCS.
Tout à fait d'accord avec Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
+1 Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!, Même si postgres fait très bien le travail aussi. Une version plus propre et un poil plus optimisé du code posté au tout début: Code (Text): // A ajouter dans le code de déclaration de la fenetre // sdClientStructure est une source de données REQ_Client est une chaîne = [ SELECT STRUCTURE_ACCUEIL.IDSTRUCTURE_ACCUEIL AS idStructure STRUCTURE_ACCUEIL.Nom AS NomStructure, CLIENT.Nom AS NomClient, CLIENT.Prenom AS PrenomClient, FROM CLIENT INNER JOIN STRUCTURE_ACCUEIL ON STRUCTURE_ACCUEIL.IDSTRUCTURE_ACCUEIL = CLIENT.IDSTRUCTURE_ACCUEIL ] QUAND EXCEPTION DANS SI PAS HExécuteRequêteSQL(sdClientStructure,hRequêteDéfaut,REQ_Client) ALORS ExceptionDéclenche(1,HErreurInfo(hErrMessage)) FIN TABLE_clientStructure..FichierParcouru = "sdClientStructure" TABLE_clientStructure..RubriqueMémorisée = "sdClientStructure.idStructure" TABLE_clientStructure.COL_NomClient..LiaisonFichier = "sdClientStructure.NomClient" TABLE_clientStructure.COL_PrenomClient..LiaisonFichier = "sdClientStructure.PrenomClient" TABLE_clientStructure.COL_NomStructure..LiaisonFichier = "sdClientStructure.NomStructure" //Version 23 TABLE_clientStructure.Affiche() //Ancienne Version TableAffiche(TABLE_clientStructure) FAIRE Erreur(ExceptionInfo(errMessage)) FIN le fait de déclarer la source de données sdClientStructure en globale de fenêtre va permettre a l'application de mapper directement les données sur la sd plutôt que de copier les valeur. Les temps d’exécution sont donc bien meilleur. C'est comme utiliser des pointeurs plutôt que des variable locale. Et si ça vous intéresse je peux vous faire la version objet qui serait vachement plus clean.