Aruba die 2.te

[KingofKning]

Hallo *all,
ich habe ja hier unter V5R4 Aruba laufen, welches per SQL auf PF-Dateien losgeht.
Die PFs sind vor 9 Jahren mal flott angelegt worden, funktionieren auch aber sind halt nie optimiert worden.

Würde es was bringen die PFs in SQL-Tabellen zu ändern?
Den RPG Programme die nachts die Dateien füllen wäre das doch egal oder?

Würde es der späteren SQL-Abfrage was nutzen? Ich will ja sowieso mit ISeriesNavigator mal schauen welche Indices er vorschlägt.

Bevor ich jetzt die Jungs von Aruba dran lasse, die mir nach 2 Tagen erzählen da tut sich unter V5R4 nicht viel möchte ich lieber selber mal schauen.

GG

[Robi]

Würde es was bringen die PFs in SQL-Tabellen zu ändern?

Eher nicht

Den RPG Programme die nachts die Dateien füllen wäre das doch egal oder?

PF / LF arbeitet mit einem Satzformat, SQL nicht (geht in der iSeries mittlerwiele aber bei V5R4?)
Dann haben die RPG Pgmme ein großen Problem

Würde es der späteren SQL-Abfrage was nutzen?

Eher nicht

Ich will ja sowieso mit ISeriesNavigator mal schauen welche Indices er vorschlägt.

DAS kann helfen, wenn von dort Vorschläge kommen. V5R4: Kein Select Omit in den LF verwenden!

viel Erfolg

[Fuerchau]

Auch in V5R4 kann man beim Create Table ein Satzformat angeben, ansonsten kann man es in RPG umbenennen.
Einen kleinen Vorteil gibt es natürlich schon:
Bei SQL-Tabellen erfolgt die Prüfung auf korrekte Inhalte beim Schreiben, beim Lesen gibt's keine Prüfung (laut Birgitta).
Bei DDS ist es umgekehrt.
Nun kann man mit RPG nur unter erschwerten Bedingungen Schrott in die Datei schreiben, mit COBOL geht das aber schon.
Fazit:
Das Schreiben wird um Micro/Nanosekunden langsamer, das lesen um den selben Faktor schneller.
Da man ggf. häufiger liest, kann man sich den Vorteil ja ausrechnen.

Greift man per ODBC zu kann man die AS/400 eher selten ausreizen da die Netzwerkgeschwindigkeit meist eine Bremse darstellt (auf der AS/400 kann ich z.B. 10000 Sätze/Sekunde verarbeiten, per ODBC max. 1000 bis 2000 je Sekunde).

Klar spielen Indizes für SQL eine Rolle, dabei ist es unerheblich ob DDS-LF (ohne Select/Omit) oder eben SQL-Index.

[KingofKning]

Hallo *all,
eine erste Analyse der DDS-Beschreibungen zeigt mir das für das BI natürlich umfangreiche Daten zur Verfügung gestellt werden sprich es wird gejoint.

Meine Frage ist aber was stört euch an einem Select/Omit?

Es kann doch eigentlich nur ein Vorteil sein unbrauchbare Daten direkt außen vor zu halten, anstatt sie im Programm oder erst im SQL zu filtern.

GG

[andreaspr@aon.at]

Bis inkl. 6.1 konnte die neue SQE mit LFs mit Select/Omit nicht arbeiten. Allein die Existenz reichte aus und die alte CQE musste die Abfrage verarbeiten.
Da kam dann ein QAQQINI Eintrag "IGNORE_DERIVED_INDEX" mit dem gesteuert werden konnte ob die DB Engine solche LFs ignorieren soll.
Nach ein paar PTFs war dieser Eintrag dann per Default auf *YES gesetzt.
Problem ist dabei halt nur, dass eventuell Abfragen wesentlich langsamer laufen, wenn wichtige Indice nicht mehr berücksichtigt werden können.

Ab 7.1 ist dieses Problem Vergangenheit, da die SQE ab da auch diese LFs untersützt.

[BenderD]

... es gibt zwei Nachteile:
- aus diesem Ansatz resultieren mehr wartbare Zugriffspfade
- diese Indexe komplizieren die Tätigkeit des Query Optimizers mehr als sie nützen (deshalb hat der die auch früher ignoriert)

D*B

[Fuerchau]

Wobei ab V7R1 diese LF's (calculated Indizes) mittels Where-Klausel genau getroffen werden müssen.
Man muss sich also eine Select/Omit-LF ansehen, aus den Select/Omit's einen where stricken und dann hoffen, dass der Optimizer den Index dann nimmt.
Bei calculated Indizes ist es insofern einfacher als das man die Where-Klausel aus dem Index direkt entnehmen kann.
Sobald man aber die Where-Klausel ergänzt kann es sein, dass der Index wieder ungünstig wird.

Was die LF-Joins angeht so sind diese meist nicht SQL-konform.
Bei SQL regelt man dies mit "Create View", das ist wesentlich flexibler.
Per View filtert man auch direkt auf die Daten.
Views haben den gewaltige Vorteil, es wird keine Index-Maintenance benötigt.
Im Gegensatz zu Indizes, die halt Wartungszeit kosten, können beliebig viele Views verwaltet werden.

Und Multiformat-Joins werden von SQL nicht unterstützt.
Dies muss man selber per "Union-Select" als View oder native stricken, geht aber auch.