Access Abfrage / Direkte Kriterien schnell / Aus Tabelle langsam

[Fuerchau]

Ich weiß nicht wofür du Aliase benötigst.
Heißt das, dass Ihr Daten einer Tabelle in mehreren Teildateien (Membern) untergebracht habt?
Wenn du mehrere Aliase hast, die alle den identischen Satzaufbau haben, kann man diese per View mittels
select * from AliasA
union all
select * from AliasB
:
zusammen fassen.
Wichtig ist Union All, da damit alle Sätze ausgewählt werden, ansonsten werden Dubletten ausgefiltert.

Performant können Abfragen nur werden, wenn sie aus genau einer Quelle zusammengefasst werden.

Zum Thema Statistiken und kleinere Queries würde ich dir da eher zu einem BI-Tool raten. Damit macht man sich das Leben sehr viel einfacher und außerdem sieht's meist besser aus.

[B.Hauser]

Aliase werden in erster Linie in Verbindung mit SQL Naming verwendet, wenn auf Objekte, die nicht im Default Schema vorhanden sind (unqualifiziert) zugegriffen werden soll.
Das hat in erster Linie nichst mit Teildateien zu tun.

Da SQL jedoch Teildateien, wie sie z.T. auf der IBM i immer noch verwendet werden, nicht kennt (partitioned Tables sind ähnlich, aber nicht ganz das gleiche), werden Aliasse gerne als permanente Objekte verwendet, um sich entprechende Overrides zu ersparen.

SQL-Views sind eigentlich nichts anderes als gesicherte SQL-Statements und können alles beinhalten, was in einem SELECT-Statement zulässig ist, mit einer Ausnahme. ORDER BY ist in einer View-Definition nicht erlaubt.
... und auch der Zugriff auf ALIASse ist in einer View-Definition erlaubt.

SQL-Views kann man mit ungeschlüsselten logischen Dateien vergleichen.

Birgitta

[Fuerchau]

"Aliase werden in erster Linie in Verbindung mit SQL Naming verwendet, wenn auf Objekte, die nicht im Default Schema vorhanden sind (unqualifiziert) zugegriffen werden soll."
In diesem Fall nehme man einfach eine View mit "Select * from Lib/Table".
Dies bietet sich auch bei Berechtigungskonzepten an, in der man bestimmte Tabellen in einer anderen Lib zum Lesen bereitstellen möchte.
Ansonsten dienen Aliase eigentlich dazu, Remotezugriffe zu vereinfachen (wobei dann keine explizite Anmeldung per Connect möglich ist, siehe DDMF) oder eben Teildateien anzugeben (bei ODBC ist es mit dem OVRDBF nicht ganz so einfach).
Natürlich kann man auch ganz normale PF's angeben, aber da finde ich persönlich Views übersichtlicher.

[AS400Noob]

Ok, jetzt kann ich wieder mal nachvollziehen wie sich manch Anwender fühlt wenn ich etwas erkläre
Ne, ganz so schlimm ist es nicht und vielen dank für eure Infos
Ein gutes BI-Tool haben wir Gottseidank schon im Einsatz (wobei das Tool von FTSolutions flexibler aussieht), nur wird immer wieder nach Daten verlangt wo man nicht darum herumkommt eigenständige Lösungen zu programmieren.


Also Beispiel warum ich Aliases verwenden: Wir haben eine Datei names MAUFTRHIS, darin wandern nach 3 Jahren sämtliche historische Aufträge um das System performant zu halten. Und jedes Historische Jahr wird in eine Teildatei aufgeteilt. H2014 H2013 usw.
Machmal will jemand eine Statistik welche auch historische Aufträge einschließt, per OCDB und Access und auch per SQL habe ich da keinen Zugriff. Darum der Umweg über Aliases.
Das ich diese per View und union all zu einer File zusammenfassen kann wird mir bei manch zukünftiger Statistik nützlich sein.

Ich werde jetzt mal meine erste View bastel und Vielen Dank für eure starke Hilfe hier

[AS400Noob]

Nachtrag: Eine View erstellt mit welcher ich die Datenmenge von 2+Mio auf ca. 300.000 eingrenzen konnte. Die identische Abfrage nur diesmal auf die View dauert nun 2 Sekunden
Somit lohnt es sich gar nicht eine 2. Tabelle und ein entsprechendes View auf beide Tabellen zu legen. Aber wenn es mal um einen größere Datenmenge geht habe ich schon die entsprechende Lösung zur Hand.

Danke!

[Fuerchau]

Das kann man mal analysieren wenn man Zeit hat. Wie gesagt, vielleicht ist die Access-Strategie da ja inzwischen optimiert worden.

[AS400Noob]

Ich werden zukünftig versuchen Access nur noch als Frontend zu betrachten und Daten und Tabellen auf der AS400 belassen. Mit den Views ergibt sich da neue Möglichkeiten samt einen deutlichen Performancegewinn. Wenn man aber nur alle paar Monate eine Statistik erstellen muss geht man zu gerne den einfachsten Weg

Diesen Tip hab ich noch erhalten:

ich würde empfehlen, die IN-Klausel gegen EXISTS zu ersetzen, was in der Regel viel schneller ist.

Bei IN werden die Daten als Tabelle geladen und verglichen, bei EXISTS wird die Vergleichstabelle nur dazu verwendet, um zu testen, ob sie existieren, dabei müssen aber keine Daten geladen werden (weswegen bei EXISTS im SELECT normalerweise nur ein Dummy wie "1" steht).

Also z.B. so:

CODE: ALLES AUSWÄHLEN

WHERE EXISTS (SELECT 1 FROM [020tDatenFuerFibu] WHERE AMERED500_BUBE51.BUBEPKTO = [020tDatenFuerFibu].[AUKDN])