Je filtre un jeu d'enregistrements DAO pour les sous-résultats dans le cadre d'un ensemble de tâches récursives. J'essaye d'accélérer la routine, et je peux voir que le jeu d'enregistrements est ouvert frais chaque fois que l'objet de classe est instancié. Cette étape se produit plusieurs centaines de fois. N'y a-t-il pas moyen de le réutiliser? Le mot-clé ici est la persistance, n'est-ce pas?Rendre un jeu d'enregistrements DAO persistant dans un module de classe
J'ai essayé de définir le jeu d'enregistrements dans l'événement Instantiate, alternativement à partir des fonctions. J'ai essayé d'utiliser static (au lieu de dim ou private) pour déclarer le jeu d'enregistrements. J'ai aussi bidouillé aussi avec la façon dont l'objet de classe est déclaré et défini.
Je connais une solution courante consiste à changer à une source SQL spécifique pour chaque appel, mais la requête qui produit le jeu d'enregistrements est elle-même lente, donc je ne vois pas cela utile. Et oui, les tables de base sont indexées de manière optimale.
Je suis heureux d'afficher du code, mais est-ce suffisant pour vous offrir des conseils?
Notez que l'indexation des champs Oui/Non alias Booklean peut également améliorer les performances. Par exemple indexer un champ Oui/Non sur une table de travail avec 2000 enregistrements a fait une grande differnece de performance dans une requête qui contenait aussi une table avec 800K enregistrements. –
Je place des index où il y aura tri/filtre .... donc si un champ Y/N sera trié ou filtré, d'accord il obtient un index. Voulez-vous dire qu'il aide à indexer un Y/N, même si elle n'entre pas dans la requête crunching? Ou voulez-vous simplement dire qu'un Y/N a besoin d'indexation comme n'importe quel autre champ, si cela fait partie de la requête? – Smandoli