Physische Dateien mit Schlüssel

[kretzsch]

Hallo,
ich bilde mir ein irgendwo gelesen oder gehört zu haben, dass physische Dateien mit Keys in der Performance ihrer Verarbeitung langsamer sein können als eine logische Datei mit gleichem Schlüssel. Wer weiß darüber etwas oder wo kann ich was nachlesen?
Gruß kretzsch

[BenderD]

... das muss die Bunte Illustrierte gewesen sein, vergiss es! Wenn ein Programm langsam oder schnell ist, das liegt eh' nicht an sowas (auch nicht an Open close, oder SQL versus DDL erstellt).

D*B

Hallo,
ich bilde mir ein irgendwo gelesen oder gehört zu haben, dass physische Dateien mit Keys in der Performance ihrer Verarbeitung langsamer sein können als eine logische Datei mit gleichem Schlüssel. Wer weiß darüber etwas oder wo kann ich was nachlesen?
Gruß kretzsch

[UFK]

Na ja, wenn man die rein physische Datei bzw. Tabelle und die rein logische Datei bzw. den Index voneinander trennt, kann (und muß) man beides separat handhaben.

Das ist einerseits aufwändiger, in manchen Situatonen aber auch praktischer. Die getrennte Einrichtung scheint mir inzwischen zukunftsträchtiger, besonders, wenn man beides nur mit SQL erstellt, und die einfachere mit DDS erstellte Datei mit Key ist halt AS400-Geschichte, die zwar immer noch zutrifft und gut funktioniert, aber vielleicht doch etwas zu AS400-spezifisch ist, um von dem Rest der Welt anerkannt und übernommen zu werden.

Fazit: in DDS erstelle ich nur noch, was nötig ist (wenn sonst alles in DDS da ist). Alles andere lieber in SQL, mit CREATE TABLE und CREATE INDEX

[Fuerchau]

Bei einem Create Table mit Constraint Primary Key wird (glaube ich) der Schlüssel in der PF abgelegt.
Der einzige Unterschied ist, dass dieser Key immer Unique ist, während man bei DDS den Key auch nicht Unique definieren kann.

[cbe]

das einzige dass mir dazu einfällt ist, dass wir zum Jahrtausendwechsel das Jahrhundert in etlichen Dateien zugefügt haben:
1. LFs gelöscht
2. Dateifeld von 6 auf 8 verlängert
3. JH zugefügt (aus 981231 wird 19981231)
4. LFs neu aufgebaut

Und wenn das Datumsfeld dummerweise im Key der PF war, wurde in 3. bei _jedem_ Satz die Datei umsortiert. Das war erheblich langsamer als in 4. die LFs am Schluss komplett neu aufzubauen.

Gruß, Christian

[BenderD]

.. wenn mans richtig gemacht hätte, hätte man die Datei maint vorübergehend auf delayed geändert und am Ende wieder auf immed.
BTW: - da wird nix sortiert
- da hätte man date Felder draus machen sollen
- da gibt es noch die Sache mit dem kaputten Zugriffspfad, wo die PF ohne Key besser abschneidet, habe ich aber noch nicht wirklich gesehen

D*B

das einzige dass mir dazu einfällt ist, dass wir zum Jahrtausendwechsel das Jahrhundert in etlichen Dateien zugefügt haben:
1. LFs gelöscht
2. Dateifeld von 6 auf 8 verlängert
3. JH zugefügt (aus 981231 wird 19981231)
4. LFs neu aufgebaut

Und wenn das Datumsfeld dummerweise im Key der PF war, wurde in 3. bei _jedem_ Satz die Datei umsortiert. Das war erheblich langsamer als in 4. die LFs am Schluss komplett neu aufzubauen.

Gruß, Christian

[cbe]

.. wenn mans richtig gemacht hätte, hätte man die Datei maint vorübergehend auf delayed geändert und am Ende wieder auf immed.
...

ach wenn ich das damals gewusst hätte...

[Fuerchau]

Manche APP's setzen FRCRATIO(1) was bei Massen-Änderungen gewaltig auf die Performance geht.
Da dauert dann eben auch ein CPYF erheblich länger.

Bei solchen Aktionen ggf. auch FRCRATIO prüfen.