LF / SQL index

[Fuerchau]

Also noch mal langsam!
Eine LF besteht aus Feldern und aus Index-Feldern.
Wenn du nun einen "CREATE INDEX ..." machst, so enthält die LF automatisch alle Felder mit dem gewünschten Index der Felder.
Willst du das selbe mit einer LF erreichen so musst du alle Felder (oder einfach das selbe Satzformat) sowie die K-Bestimmung für den Index angeben.

Machst du eine LF mit nur 3 Feldern und dem Index über diese 3 Felder, ist das für SQL eine VIEW (unabhängig vom Index).
Views finden beim Index suchen aber keine Rolle, da diese (bei SQL) ja auch keinen Index haben.

Nun können wir aber auch aneinander "vorbeireden" und du erstellst die LF per DDS mit allen Feldern.

Was nun beim Optimizer passiert und was ich immer wieder erlebe ist, dass der vorgeschlagene Index anschließend nicht genommen wird!
Da kann man sich dann auf den Kopf stellen wie man will.

"Felder und Reihgenfolge passen mit dem Vorschlag des Advisors überein" bezieht sich ausschließlich auf die Schlüsselfelder!
Mach doch einfach folgendes:
Lösche deine LF und erstelle einen Index per "create index mylib/myindex on mylib/myfile (f1, f2, ...)" und prüfe das Ergebnis per SQL.

[UFK]

Mach doch einfach folgendes:
Lösche deine LF und erstelle einen Index per "create index mylib/myindex on mylib/myfile (f1, f2, ...)" und prüfe das Ergebnis per SQL.

Das Dingens wird wohl vewendet werden, also die Lösung sein.

Unschön ist die Macke beim SQL dennoch, denn früher hat man auf speziell für den Anwendungsfall formulierte logische Dateien gesetzt, die man dann konventionell mit RPG oder COBOL vewendet hat. Da treffen also Weltanschauungen aufeinander, DDS-Welt der AS400 gegen die SQL-Welt, und IBM kann es keinem der beiden wirklich recht machen.

Obendrein hat die DDS-Ansicht dazu geführt, daß manchmal sehr viele LF's über denselben physischen Dateien erstellt wurden, und der SQL-Optimierer spätestens bei der vierzigsten das Handtuch geworfen und beschlossen hat, lieber den Index selber zu erstellen, als weiter darüber zu brüten, welcher der vielen Zugriffswege denn optimal sein könnte.

Ich hatte auch mal Ärger mit dynamical select Join auf DDS-Basis, die jedesmal zur Neuindexierung von Millionen Datensätzen führten, obwohl die LF's eigentlich sofort nutzbar gewesen wären. Besser wurde es bei mir durch spezielle Indizes und simpel formulierte SQL-Anfragen, welche die SQL-Engine leichter mappen konnte. Besser als das Neu-Indexieren oder als das sequentuelle Scannen des kartesischen Produktes waren aber auch Selects mit korrelierten Subselects.

Interessant, daß IBM die Leute immer noch ins Messer rennen läßt, und sogar in Kauf nimmt, System-i Kunden zu vergraulen.

PS: habt Ihr euch schonmal mit der QAUOOPT beschäftigt ?

[Fuerchau]

Das liegt nicht an IBM sondern am SQL-Standard an den sich die IBM weitestgehend auch hält.
SQL und DDS ist absolut nicht vergleichbar. man kann zwar Analogien ziehen aber es gibt doch wesentliche Unterschiede.
Wenn man sich mit SQL-Konzepten nur an Hand von DDS beschäftigt ist man natürlich verraten und verkauft. So funktioniert SQL einfach nicht.
DYNSLT-Joins, wie der Name schon sagt, muss halt Indizes aufbauen und ist bei DDS eigentlich die schlechteste Lösung, eben mangels Index, performant waren die noch nie.
Und wenn man nun noch komplexe SQL's erfindet die man so überhaupt nicht programmieren würde, dann kann auch der Optimizer nichts mehr leisten.
SQL-Zugriffe müssen genauso wohl überlegt sein wie DDS-Zugriffe mit Native-IO und 100en LF's (die auch Maintenance-Zeit kosten).