SQL Update

[andreaspr@aon.at]

hi birgitta,
danke für die aufklärung, dass beim lesen und schreiben die tabellen unterschiedlich geprüft werden wusste ich noch nicht. beiträge von dir baldur und bender sind immer eine wissensbereicherung! :)

lg andreas

[BenderD]

... so neu und überraschend (und so ganz richtig) ist das mit dem prüfen nicht.

überraschend nicht: DDS und RLA braucht sowas, schon wegen der Möglichkeit Multiformat Dateien zu verarbeiten

neu nicht: das war in vor SQL Zeiten generell so (Stichwort: ISAM Dateien)

so ganz richtig nicht: Konsistenzbedingungen, die beim schreiben geprüft werden gibt es auch bei DDS und RLA (Stichwort: Key Bedingungen) und ob die nahe an der Datei oder im generierten Code von RLA geprüft werden (Range Bedingungen) ist eher nicht Laufzeit relevant) SQL kann halt mehr an Konsistenzbedingungen - und geschenkt kriegt man nichts. SQL macht als streng Typ gesicherte Sprache auch beim lesen Prüfungen (typischerweise mehr als RLA!!!)

Im richtigen Leben geben sich diese Effekte in der Summe (!!!) nichts, in Einzelkonstellationen kann es da durchaus Ausreißer nach unten oder oben geben, die solche Effekte über Messbarkeitsschwellen heben.

Mein Resumee dabei:
- SQL hat in der Summe die Nase vorn, wenn ich genügend Hardware habe.
- RLA und DDS können bei Ressourcen Engpässen zuweilen noch was retten.
- Die Programmierer Performance spricht eindeutig für SQL!!!

D*B

[Fuerchau]

Ausserdem muss man bei RPG/LE noch bedenken, dass der Compiler implizit Feldprüfungen sowieso einbaut.
Dadurch, dass RPG/LE nicht direkt mit den Satzpuffern arbeitet werden intern MOVE-Befehle zwischen Datenfeld und Dateipuffer generiert.
Wenn dabei was nicht stimmt (ins besonders Dezimalfelder) gibts halt MCH-Fehler.
Auch wenn man sich die Auflösung der SQL's im Spool ansieht, sieht man eine Vielzahl von Move's, die ja auch bei Dezimalfeldern durch MI geprüft werden (dies läßt sich auch nicht abschalten).

Einzig wenn man Dateien nicht als extern, sondern intern beschrieben verarbeitet, also quasi Satz- und nicht Feldweise, kommt es bei DDS-Dateien weder beim Lesen noch beim Schreiben (Ausnahme Key's und Integritätsbedingungen) zu Fehlern, nur bei SQL-Dateien wird eben mehr geprüft.

COBOL-Leute wissen das meistens, da COBOL grundsätzlich mit den Satzpuffern direkt arbeitet.
Beim Lesen und Schreiben erfolgen nämlich keine MOVE's mehr.
Dadurch erklärt sich auch (mehr aus der Vergangenheit) die etwas bessere Performance bei Datei-IO als bei RPG/LE.

Beispiel:
Häufig werden in RPG/LE von einer Datei nicht alle Felder bearbeitet.
Man findet aber auch dann diese Kombination:

FDATEI UF E K DISK
EDATEI E DS
IDATEI

Beim Lesen werden alle Dateifelder in die DS übertragen, beim schreiben alle wieder zurück.
Läßt man die DS-Struktur weg, generiert der Compiler ausschließlich die MOVE's der verwendeten Felder (das erklärt auch, warum im Debugger ggf. Felder nicht angezeigt werden können).

Bei Massenupdates (Batch) werden eben 100.000de oder Millionen von unnötigen Moves ausgeführt um vielleicht nur 1 Feld einer Datei zu ändern.

Bei COBOL werden aber keine zusätzlichen Moves generiert, die Laufzeit ist also besser.

Man kann also unabhängig vom Dateisystem (DDS/SQL) nicht unerhebliche Performance-Verbesserungen erreichen, wenn man das berücksichtigt.

[BenderD]

... das Alter erzieht da zu Pessismismus: ich habe im Verlaufe meines Berufslebens zuviele Programme gesehen, wo der Programmierer vor lauter Performance Optimierung die Stellen übersehen hat, wo er/sie das 10 fache wieder weggegeben hat, was er wo anders mit Mühe eingespart hat. Wer da Ideen braucht, wie man sowas macht:
- sequentielles lesen gelöschter Sätze
- Hundertfach denselben Satz lesen
- update von Hunderttausenden ungeänderter Sätze
- Millionenfaches Konvertieren des heutigen Datums
- weitere Ideen findet man in historisch geschrumpften Anwendungen

Konsequenz: simple ist meist gut!

D*B



Man kann also unabhängig vom Dateisystem (DDS/SQL) nicht unerhebliche Performance-Verbesserungen erreichen, wenn man das berücksichtigt.