Query mit Eingangsfolge

[B.Hauser]

weil eben QUERY/400 sonst nach Eingangsfolge liest

Tut es eben nicht!
Auch beim Query/400 wird der Query Optimizer (wenn auch nur alte Query Engine) aktiviert, der einen optimalen Zugriffsweg ermittelt und diesen verwendet. Die Verarbeitung nach Eingangsfolge (sprich Table Scan) erfolgt nur dann, wenn der Optimizer KEINEN optimalen Zugriffsweg findet!

Nach Deinem Verständnist würde also bei jeder Abfrage, bei der keine Sortierung angegeben wurde die komplette Datei durchgelesen werden, das braucht bei in paar Milliönchen Sätzen schon seine Zeit. Zugegebenermaßen kann der Optimizer bei der CQE z.T. durch die Angabe einer Sortierung beeinflusst werden, aber es gibt dafür keine Garantie.

Beispiel: Aus einer Auftrags-Kopf-Datei werden alle Aufträge für Kunde 4711 ausgewählt, aber nach Bestell-Nr. sortiert. Es sind sowohl Zugriffswege über die Kunden-Nr. als auch die Bestell-Nr. vorhanden. Obwohl die Sortierung nach Bestell-Nr. angegeben wurde, wird wahrscheinlich der Zugriffsweg über die Kunden-Nr. verwendet, alle Sätze ausgelesen und zum Schluss sortiert.

Wenn Du's nicht glaubst, starte einen Database Monitor und analysiere die Ergebnisse. Da wirst Du sehen, dass auch bei Query/400-Abfragen Zugriffswege verwendet werden.

Birgitta

[alfredo]

In der Praxis werden die Anwender wohl lieber eine Auswertung aufsteigend nach dem Gruppierungsbegriff und nicht nach Erstellungszeitpunkt haben wollen.

[alfredo]

Beispiel Datei TESTQUERY, Key=KEY
select key
from testquery
group by key
KEY
7
6
5
4
3
2
1
select key, count(*)
from testquery
group by key
KEY COUNT ( * )
1 1
2 1
3 1
4 1
5 1
6 1
7 1

[Fuerchau]

Du musst unterscheiden zwischen der Query-Gruppierung und einem Group-By !

Beim Query muss eine Sortierung angegeben werden, wenn die Gruppierung sinnvolle Summen auswerfen soll.
Da beim Query sowohl die Einzelsätze als auch die Gruppensummen ausgewiesen werden können (in mehreren Stufen), erfolgt eben erst die Sortierung (falls angegeben) und anschließend eine ganz normale Gruppenwechsel-Verarbeitung.
Der Optimizer betrachtet beim Query im Wesentlichen die Satzauswahl und die Sortierung.
Von der anschließenden Gruppierung weiß er nähmlich nichts.

Bei SQL sieht das anders aus.
Da hat man nur 2 Möglichkeiten:
- nur Einzelsätze
- nur Gruppierung über max. 1 Ebene
Der Optimizer entscheidet hier jeweils über
- where
- Group
- having
- order
Klausel, wobei die Sortierung nicht eindeutig ist wenn man order-by weglässt, egal ob group-by oder nicht.

@Birgitta
Das mit der View geht solange gut, solange man wenige Sätze hat.
Da der Optimizer nun mal immer auf der PF aufsetzt, habe ich zwar für Query nun die Satznummer, aber bei einer Sortierung nach dieser erfolgt eben immer ein Table-Scan und zwar unabhängig von jedweder Verfügbarkeit von LF's (ich habe es mit einer 2,5Mio-Date bei V5R3 ausprobiert).
Lasse ich die Sortierung weg, klappts auch mit den LF's.
Ich denke, das liegt daran, dass die RRN eine Funktion und kein Feld ist. Bei Sortierung nach UDF's siehts genauso bescheiden aus.

Wenn ich aber weiß, dass das Zwischenergebnis nur ein paar 1000 bis 10.000 Sätze sind, ist das über einen Insert/Select bzw. Create/Select um Faktoren schneller.

@Frank
Prüfe mal an deiner Tabelle, ob REUSEDLT(*YES) eingeschaltet ist. Dann ist deine Eingangsfolge nähmlich keine mehr und das Problem löst sich in Luft auf.

[alfredo]

Gut wenn man soviel Zeit zum Philosophieren hat...

[Fuerchau]

Das hat mit Philosophieren nichts zu tun.
Wenn man die Unterschiede nicht kennt und verinnerlicht, wundert man sich halt über das Ergebnis .

Oder fragt hier