View vs LF / Performance

[B.Hauser]

@Birgitta
Aussage 3 verstehe ich nun überhaupt nicht mehr !
Prüfung beim Lesen und nicht beim Schreiben ?
Welchen Sinn sollte das denn machen, dann würde ich ja beim Schreiben ungültige Daten wegschreiben können (was nachweislich z.B. bei Datum-Typen nicht geht) ?!

Mach mal folgendes Beispiel:
1. Datei mit CRTPF und fester Satz-Länge.
2. In diese Datei füllst Du irgendwelche alphanumerischen Daten.
3. Erstelle eine DDS-beschriebene Datei mit einem (oder mehreren numerischen Feldern)
4. Kopiere Datei 1 mit CPYF und FMTOPT *NOCHK in die DDS beschriebene Datei.
5. Mit WRKF wirst Du feststellen, dass der (oder die) Datensätze anstandslos übernommen wurden.

6. Jetzt erstelle die gleiche physische Datei (mit den numerischen Feldern) mit CREATE TABLE.
7. Kopiere Datei1 in diese mit SQL erstellte Datei (wieder mit CPYF und FMTOPT*NOCHK),
8. Jetzt wirst Du feststellen, dass kein Datensatz mit ungültigen Daten in die Datei übernommen wurde.
9. Alternativ kannst Du auch das Joblog prüfen.

Das sind so kleine Unterschiede zwischen DDS und SQL beschriebenen Dateien, die aber bis zu 40% Performance-Steigerungen mit sich bringen können, da in einer herkömmlichen Anwendungen weit mehr Lese- als Schreib-Operationen erfolgen. Die sonstigen Prüfungen, auf die Du anspielst, werden z.B. von RPG druchgeführt.

Welchen Sinn das Ganze macht, und warum das so ist, kann ich nicht sagen. Der Grund dafür wird wohl sein, für alte (/36 oder noch älter) Anwendungen eine Prüfung der Daten beim Einlesen der Daten erfolgen musste um Dezimal-Datenfehler u.ä. zu vermeiden, während die andere Vorgehensweise im SQL-Standard definiert ist.

Wer gerne mehr darüber wissen möchte, findet in der iNN - eNews vom Juni einen aktuellen Artikel von Dan Cruikshank:
Performance Comparison of DDS-Defined Files and SQL-Defined Files

Birgitta

[Fuerchau]

Ja OK, den guten alten LVLCHK habe ich nicht berücksichtigt.
Dieser ist nur bei DDS möglich.

Allerdings prüft das System beim Schreiben per RPG auch DDS-Dateien, wenn LVLCHK aus ist.

Beim Lesen solcher kaputter Dateien, gibts allerdings bei RPG meist keinen Fehler, da Dezimalfehler ignoriert werden.
Beim ILE gibts dann wiederum trotzdem Fehler, wenn nicht explizit FIXNBR angegeben ist.

Wenn ich denn dann die DDS-PF per SQL bearbeite erfolgt auch beim Schreiben die Typprüfung.

Sicherlich ist beim Lesen der DDS-PF für SQL immer eine Typprüfung erforderlich. Dies kann aber nicht obiges Problem sein, da die PF ja DDS-beschrieben ist und somit SQL über die View als auch über die PF eine Typprüfung machen müsste.

Allerdings konnte ich bisher keinen nennenswerten oder performancerelevanten Unterschied zwischen DDS und SQL-Dateien feststellen (auch bei Dateien mit mehr als 10.000.000 Sätzen, DDS-beschrieben).
Die Performance konnte immer durch gezielte Erstellungen von Indizees massiv beeinflusst werden !

[Robi]

So, umfangreiche Tests auf unsere AS400 mit extra erstellten großen Dateien (2 mio Sätze) haben ergeben :
alles was ich geschrieben habe muß Quatsch sein.
alles was ihr geantwortet habt ist die Praxis (bei uns).
Trotzdem ist auf der KD-AS400 eine identische VIEW deutlich schneller als Sql-lesen eines PF.
Ich geb auf!
Der Kd ist zufrieden, da wir auf VIEW umgestellt haben.
Vielleicht fehlt ihm ja ein PTF, das sql-lesen wieder beschleunigt. Habe der EDV eine entsprechende Info gegeben.
Ich Danke Euch für eure Hilfe
Gruß
Robi