Is een query van een query een goed idee?

Goedeavond,

Ik heb een tabel met zo'n 1,5 miljoen records, met 10 kolommen.

Is het beter om met een query de gewenste dingen direct uit de bron te halen, de tabel? En maakt het uit of die bron een gelinkte tabel is of dat het een tabel in Access zelf is?
Of is het beter om in een tussenquery alleen de kolommen op te nemen die je nodig hebt (2 kolommen), en een query met variabele criteria (criteria die verwijzen naar een tekstveld in een formulier) los te laten op de tussenquery?

Dat ik hier zelf het antwoord niet op heb komt omdat ik niet zo goed weet hoe een query 'werkt'. Ik snap het eindresultaat natuurlijk, maar ik weet niet of een computer de gegevens in een tussenquery (die alleen bepaalde kolommen opneemt) zijn werk al gedaan heeft als je met een tweede query gegevens uit de tussenquery laat filteren en optellen oid. Hoeft de 'eindquery' dan slechts door 2 kolommen te gaan ipv 10? Als de tussenquery zijn werk al klaar heeft liggen zou dat een goed idee zijn.

Kan iemand mij hier inzicht in verschaffen?

De resultaten krijg ik na enkele seconden. Ik zie soms even 'reageert niet' bovenin het scherm. Is daar nog iets bij in te stellen? Kan ik Access 'vertellen' dat het 'reageert niet' pas na bijvoorbeeld 30seconden getoond hoeft te worden?
Voor mij als gebruiker zou die tekst de indruk wekken dat het programma op het punt staat vast te lopen. Beter niet tonen dus, als het normaal is dat het 10 seconde duurt voordat een resultaat zichtbaar is.

Met vriendelijke groet,
Visara

Een query op een query zal je eindresultaat eerder langzamer maken dan sneller, maar jij kunt dat makkelijker testen dan ik, want jij hebt die data voorhanden. Ik ga echt geen 1,5 miljoen records vullen voor een duur test . Dus rest het gewoon eens uit. Wél heeft het zin om je dataset gelijk goed te filteren, als je snelheidsproblemen ondervindt.
En als je de data uit een SQL server haalt, kun je daar wellicht een view maken die sneller is.
Meldingen kun je vermoedelijk wel onderdrukken, en vervangen door een formulier dat met een ‘progress bar’ werkt, waardoor het lijkt alsof er wat gebeurt. Je kunt ook nog naar de time-out instellingen kijken, maar die zullen je denk ik niet veel soelaas bieden.

Bedankt voor uw reactie.
Ja, ik testte het zelf ook. Leek langzamer met extra query, maar wist niet zeker of dat per definitie kwam door de extra query of door een voor mij onbekende reden.
Wel een beetje jammer dat u niet even snel 1,5 miljoen records aanmaakt om te testen Geintje, ik was gewoon benieuwd naar een algemene richtlijn.

U schreef:

om je dataset gelijk goed te filteren

Klik om te vergroten...

Niet met een "tussenquery" dus. Bedoeld u bijvoorbeeld dat ik er voor zorg dat ik met een bron kan werken die van alle onnodige data is ontdaan?

Ik denk dat niemand met een recordset van 1,5 miljoen records gaat werken; dat zal altijd op een deel van de records zijn. Door een query te maken met een WHERE clausule kun je dat deel er simpel uitfilteren, en dat maakt in ieder geval het formulier een stuk sneller. Met een virtuele recordset kan het dan nog wat verder versneld worden, want een recordset die één keer in het geheugen is geladen, werkt verder natuurlijk supersnel.
Maar ik dacht dat je vorige maand pas je eerste database hebt gemaakt; om dan gelijk al met 1,5 miljoen records te gaan werken, lijkt mij nogal ambitieus .

Ik werk met WHERE in queries. Wist niet dat dit dingen versnelde, dacht dat het net zo iets is als criteria en dat alsnog de complete tabel doorlopen moest worden.

Ben inderdaad vorige maand begonnen, vooralsnog gaat het goed

Een query wordt in verschillende stappen uitgevoerd:
• Syntax controle: de SQL statement wordt gecontroleerd op taalfouten.
• Parsing: de SQL statement wordt in kleine stukken gehakt om te kunnen bepalen welke tabellen en velden er allemaal meespelen.
• Opstellen van het executieplan: de database gaat na hoe de verschillende onderdelen het snelst kunnen gecombineerd worden.
• Compilatie en opslaan: wanneer men de query opslaat nadat het executieplan is aangemaakt wordt deze samen met het aangemaakte executieplan opgeslagen en wordt dus de volgende keer sneller uitgevoerd. Wanneer men de query wijzigt of bij een parameterquery moeten alle stappen echter opnieuw uitgevoerd worden.

In een SQL expressie wordt eerst de FROM uitgevoerd, dan de WHERE , dan de SELECT en als laatste de ORDER BY.

Dus bij meerdere queries moeten al deze stappen voor elke query uitgevoerd worden.

Wat wel helpt bij het versnellen van een query is het gebruik van indexen. Geïndexeerd zoeken gaat steeds sneller dan een full table scan. Vergelijk het met een woord zoeken door een compleet boek te lezen, of eerst in de index te gaan kijken waar het woord te vinden is. Velden waarop een join gebeurt moet je steeds indexeren, alsook de velden waarop je vaak zoekt. Echter niet teveel indexeren want bij elke update van een geïndexeerd veld moet ook de index bijgewerkt worden en indexen worden in de database bewaard, dus maken de database groter.

Je vergeet de HAVING . Die overigens ná de WHERE zit, dus daarom is het altijd handig om te filteren met WHERE. Maar inderdaad, met de juiste indexen versnel je de query (en zoeken in tabellen) aanzienlijk.

HAVING kan je alleen gebruiken met een GROUP BY, want die werkt met de resultaten van de GROUP BY en is dus een ander type criterium dan WHERE
dan heb je: FROM - WHERE - GROUP BY - HAVING - SELECT - ORDER BY

En zo is-tie compleet .