Wieso Weshalb Warum zu Abfragen???

[Maximilian]

Hallo Zusammen,

seit ein paar Tagen stelle ich mir die Frage, wann man überhaupt eine explizite Abfrage in Access erstellen sollte bzw. wann es sinnvoll wäre?

Bisher habe ich in der Datenherkunft von Formularen, Listboxen, Kombinationselementen, etc. direkt die entsprechenden Kriterien eingesetzt und somit keine extra Abfrage erstellen müssen.
Nur vermute ich, dass eine extra Abfrage auch Vorteile haben kann, die ich bestimmt wieder nicht kenne...

Danke schonmal für eure Aufklärung 
Grüße,
Maximilian

[MzKlMu]

Hallo,

etc. direkt die entsprechenden Kriterien eingesetzt

Wie hast Du das genau gemacht ?
In einer Datenherkunft kann man keine Kriterien einsetzen.

[Maximilian]

Für Formulare:
In der Entwurfsansicht kann ich auf dem Eigenschaftenblatt, Reiter "Daten" unter dem Punkt "Datensatzquelle" einen Abfrage-Editor öffnen.

Bei Listboxen und Kombinationsfeldern nennt sich das ganze "Datensatzherkunft"

Im Anhang zwei Screenshots. Jeweils durch Klick auf die Schaltfläche mit den drei Punkten öffnet sich der Abfrage-Editor.

[MzKlMu]

Hallo,
das sind doch die Abfragen das sind doch keine Kriterien.
Diese Abfragen sind gespeicherten Abfragen gleich zu setzen.

[Maximilian]

Ah okay.
Wann würde man denn gespeicherte Abfragen verwenden?

[MzKlMu]

Hallo,
wenn die Abfragen etwas komplizierter/größer werden kann man die speichern.
Gespeicherte Abfragen kann man auch in der SQL Sicht ansehen.
Das kannst Du machen wie es Dir am Besten gefällt.

[DF6GL]

Hallo,


als "einfache" Erklärung:

Eine gespeicherte ("explizite") Abfrage ist als solche kompiliert und damit "sofort" ausführbar.

Ein SQL-String muss immer, sobald er verwendet wird, erneut kompiliert und dann ausgeführt werden.

Soll heißen, es gibt eine kleine Performance-Einbuße

[MzKlMu]

@Franz
das habe ich bisher auch so geglaubt. Aber laut Eberhard (Ebs) aus dem MOF ist das nicht der Fall.
Auch die Abfragen die direkt mit Select.. in die Datenherkunft geschrieben werden, werden kompiliert abgelegt.
Ich glaube, da hat er auch mal eine Abhandlung dazu geschrieben. Muss mal schauen, ob ich das finde.

[PhilS]

Wann würde man denn gespeicherte Abfragen verwenden?

Ein wichtiger Punkt wurde noch nicht genannt.

Kapselung
Beispiel: Du hast eine komplexe Abfrage, die zu einem Firmenkunden den primären Ansprechpartner, das letzte Bestelldatum und den Gesamtumsatz aller Bestellungen zeigt. Diese Informationen möchtest du jetzt in einer umfangreichen Anwendung überall dort anzeigen, wo ein Kunde ausgewählt/angezeigt wird.

Du erstellst einmal die Abfrage und speicherst sie. In den zahlreichen Formularen/Listen/Dropdowns in denen die Daten dargestellt werden beziehst du dich (ggfls. mit zusätzlichen Kriterien) auf diese Abfrage. - Wenn sich nun an der grundlegenden Abfragelogik etwas ändert (und die Output-Splten gleich bleiben) machst du das einmal in der Abfrage und nicht in allen Formularen, wo die Daten dargestellt werden.

[PhilS]

Auch die Abfragen die direkt mit Select.. in die Datenherkunft geschrieben werden, werden kompiliert abgelegt.

Richtig.
Man sieht sie in den MSysObjects unter dem Namen ~sq_Formular~sq_Steuerelement.

[DF6GL]

Hallo,

ja, ich kenne die temporären (internen) Abfragen  natürlich auch.

Nur frag sich, ob nicht  jedes Mal,  sobald z. B. ein Formular aufgerufen wird, der SQL-String erneut kompiliert wird.

Eine Abhandlung darüber interessierte mich auch.

[ebs17]

Performance in Abfragen von Michael Zimmermann
=> Seite 31
Solch ein Standardwerk zu grundlegendsten DB-Techniken sollte man wenigstens 20-mal gelesen haben.

Eine gespeicherte Abfrage ist deutlich schneller als SQL-Code, der in VBA-Code dynamisch erzeugt wird; in meinen Tests um bis zu 400%

Das betrifft aber Abfragen OHNE DATEN. Daten (Laden und deren Verarbeitung) selber machen dann auch Arbeit, und zwar dann deutlich mehr als die Vorausplanung zur Abfrageausführung (Syntaxprüfung, Tätigkeit des Jet-Optimierers, Ablage des ermittelten Ablaufplanes).

Was man sich auch bewusst machen sollte: Der Ablaufplan für die Abfrage liegt NACH der ersten Abfrageausführung vor. Ändert man also laufend die Abfragedefinition, um die Abfrage dann jeweils einmalig auszuführen, gibt es keinen wiederverwendbaren gespeicherten Ablaufplan, auch nicht in einer gespeicherten Abfrage.

Der Performancevorteil bei Nutzung eines gespeichert vorliegenden Ablaufplanes bemaß sich bei meinen Versuchen in Bruchteilen von Millisekungen bis hin zu niederen einstelligen Millisekundenbeträgen.
In der Literatur habe ich gelesen, dass das bis zu etwa 8 Sekunden gehen kann. Die Abfragen, die erst 8 Sekunden optimiert werden, eh es an die Ausführung geht, wollen aber erst einmal erdacht werden (liegt außerhalb meiner Vorstellung und erst recht Erfahrung).

Ja, und bezüglich Performance sollte man sich erst einmal mit Abfragedesign und Indexnutzung beschäftigen - der Optimierer kann nur das verarbeiten, was ihm vorgegeben wird.

[Maximilian]

Wow das Thema ist ja doch komplexer als ich mir hätte vorstellen können 

Auf jeden Fall ist meine Frage für mich zumindest beantwortet, lese hier aber gerne weiter. Auch wenn die Hälfte für mich noch böhmische Dörfer sind, ist es trotzdem spannend 

[ebs17]

Kapselung ... kann man hier auch so verstehen:
Die Datenherkunft eines Formulars, eines Listenfeldes, eines Kombinationsfeldes gehört inhaltlich zu dem verwendeten Formular. Da macht es sich nicht schlecht, wenn sie da auch gleich platziert wird (=> wird somit Bestandteil der Formularklasse).
So muss man im Nachgang nicht aufdröseln, wo denn nun überall eine Abfrage verwendet oder ob sie überhaupt verwendet wird.

Auch ein Gesichtspunkt: Manche legen Wert darauf, dass verwendete Abfragen nicht verändert werden können. Ja manchmal sollen Fremde die Designleistung nicht mal zur Ansicht bekommen. Bei gespeicherten Abfragen bekommt man das nicht sicher hin. Einen Formularentwurf kann man über die Erstellung einer ACCDE unzugänglich machen, damit auch integrierte Abfragen.