Frage wegen DDS, CONCAT Funktion

[a.wojcik]

Geht das in RPG ? Sorry, wusste ich nicht - ich probiere es aus, danke.

[Fuerchau]

Bei den berechneten Indizes steht man vor dem Problem, dass der Optimizer diese nur verwendet, wenn man genau die selben Informationen, also hier den Concat und die Whereklausel, in einem SQL verwendet.
Weicht man auch nur in kleinster Weise davon ab, wird der Index nicht verwendet und SQL sucht sich was anderes.

Also dies könnte dann klappen:

SELECT * FROM TEST/TESTKOPF

WHERE
DIGITS (SUBSTR(TEXT, 21, 4)) CONCAT
DIGITS (SUBSTR(TEXT, 18, 2)) CONCAT
DIGITS (SUBSTR(TEXT, 15, 2)) = 'XXXX'
AND POSSTR(TEXT, 'DISPONIERT') > 0
and SATZ_KZ = 'STATI'
and LIEFNR < 990000000

[B.Hauser]

Geht das in RPG ? Sorry, wusste ich nicht

Das wissen die wenigsten.
Tatsache ist, dass die Erweiterungen in der Index-Definition (Spalten-Auswahl, zusätzliche Spalten udn WHERE-Bedingungen) in Release 6.1 in erster Linie für native I/O eingeführt wurden.
Erst mit Beginn von Release 7.1 werden in den Optimizer mehr und mehr Erweiterungen eingebaut, so dass auch SQL diese Indices optimal nutzen kann.

Birgitta

[a.wojcik]

Hallo *All,
den Index habe ich erneut erstellt und mit dem SELECT von Fuerhau ausprobiert - ist suoer schnell.
Später probiere ich den Index im Programm aus.

Danke für Eure Unterstützung !
Schönes Wochenende
AW

[Fuerchau]

Seit wann macht SQL etwas "in erster Linie für native I/O" ?
Meine Erfahrung ist, SQL macht was für SQL.

Wenn man nur native I/O programmiert kommt man doch gar nicht auf die Idee, dass SQL was dafür bereit hält.
Also ich denke, dass ist eher schlechtes Marketing.
Dieses Concat-Gedöns (vor allem bei Datumsfeldern) dient ja nur der optimalen Nutzung von Between-Vergleichen, da dies mit Einzelfeldern nicht funktioniert.

In anderen DB's gibt es z.T. schon länger "calculated Indices" die von der SQL-Engine auch gut genutzt werden konnten, eben nach obigen Kriterien.

[B.Hauser]

SQL macht nichts für SQL!

Aber IBM macht was für RPG und SQL.
Warum sollte IBM sonst z.B. Satz-Format-Namen, die nicht Standard sind beim CREATE TABLE, CREATE INDEX, CREATE VIEW zulassen?

Die Optimierung der neuen Indices war und ist nicht ganz trivial, deshalb wurden die neuen Indices zunächst nur mit native I/O verwendet. Ansonsten hätte man diese Indices solange zurückhalten müssen, bis die Optimierung abgeschlossen gewesen wäre.

Ich kann mich an diverse Ankündigungen, Artikel, Präsentationen etc. zu Beginn von 6.1 erinnern, in denen erklärt wird, dass DDS stabilisiert sei und man anstelle von DDS beschriebenen logischen Dateien (derived and sparsed) Indices verwenden solle.

Birgitta