Frage wegen DDS, CONCAT Funktion

[a.wojcik]

Ich werde es zuerst in einer Testumgebung ausprobieren, thanks.

[Fuerchau]

Die einmalige Zeit der Indexerstellung steht ggf. der Summe der eingesparten Laufzeiten gegenüber. Dabei spielt die Größe des Index keine Rolle.

[a.wojcik]

Ich habe eine Sache dabei vergessen - die Datumsfelder kann ich nur unter bestimmten Bedigungen aus einer Stelle rausschneiden - also ein Index für die ganze Datei entfällt; man kann kein "where" im Index haben. Sonst wäre es richtig so:
CREATE INDEX TEST/TESTIDX
ON TEST/TESTPF
( (SUBSTR(TEXT, 25, 4)) CONCAT
(SUBSTR(TEXT, 22, 2)) CONCAT
(SUBSTR(TEXT, 19, 2)) AS DATECHAR ASC )
RCDFMT TESTPFF1 ADD ALL COLUMNS
Habe ich mit einer vorselektierten Test Datei ausprobiert.

[Fuerchau]

CREATE INDEX TEST/TESTIDX
ON TEST/TESTPF
( (SUBSTR(TEXT, 25, 4)) CONCAT
(SUBSTR(TEXT, 22, 2)) CONCAT
(SUBSTR(TEXT, 19, 2)) AS DATECHAR ASC )

WHERE ...........

RCDFMT TESTPFF1 ADD ALL COLUMNS

[B.Hauser]

WHERE-Bedingungen sind bei Indices erlaubt.
Wie sieht denn Deine Syntax mit der WHERE-Bedingung aus?

Birgitta

[a.wojcik]

Hallo Birgitta,
Es könte so ausehen (ausprobiert):
CREATE INDEX TEST/TESTIDX1
ON TEST/TESTKOPF
(DIGITS (SUBSTR(TEXT, 21, 4)) CONCAT
DIGITS (SUBSTR(TEXT, 18, 2)) CONCAT
DIGITS (SUBSTR(TEXT, 15, 2)) AS DATECHAR ASC )
WHERE POSSTR(TEXT, 'DISPONIERT') > 0
and SATZ_KZ = 'STATI'
and LIEFNR < 990000000
RCDFMT TESTKOPFF1 ADD ALL COLUMNS
- aber wie kann diesen Index nutzen ? Direkt selektieren geht damit nicht.

[B.Hauser]

Ich dachte Du wolltest mit native I/O und nicht mit SQL zugreifen!
Native I/O kann SQL-Indices wie jede geschlüsselte Datei verarbeiten.
(In SQL kann/darf man einen Index nicht direkt angeben! Der Optimizer sucht sich den Zugriffspfad)

Birgitta

[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.