i5 und SQL

**Fuerchau** · 14-11-08, 15:36

Wenn du die Daten nur von rechts nach links kopierst, kannst du auch einen

insert into fileb
select * from filea

codieren.
Desweiteren erlaubt der "Fetch into" auch als Ziel eine Struktur.
COPY-DDR funktioniert auch auf SQL-Tables, so dass du hier nicht alles explizit definieren musst.

Für reine Kopierarien reicht
CPYF
QM-Query mit obigem Insert...Select.

**B.Hauser** · 14-11-08, 15:57

Hallo,

der Hauptgrund warum man SQL Tabellen verwenden sollte ist der, dass in SQL-Tabellen (z.B. in gepackte numerische Felder) kein Schrott eingefügt werden kann. Selbst bei einem CPYF mit *NOCHK können keine ungültige Daten in die Datei geschrieben werden.

Intern in SQL Tabellen wird immer beim Reinschreiben auf gültige Daten geprüft, während bei DDS beschriebenen Dateien immer erst beim Lesen geprüft wird. Wenn man sich das Verhältnus von Lese zu Schreib-Operationen überlegt und dann im Hinterkopf behält, dass eine Prüfung der Daten wenn auch nur minimal Zeit kostet, kann man sich vorstellen, dass die Verarbeitung mit SQL-Tabellen performanter wird (im Vergleich zu DDS beschriebenen physischen Dateien).

Des weiteren wurde die Entwicklung von DDS schon lange "stablilisiert" wie IBM so schön sagt, sprich eingestellt. Seit V5R1 sind alle Neuerungen, in CREATE TABLE nur noch in SQL erfolgt, z.B. das Definieren von Identity Columns, die Verwendung von Large Object-Datentypen, die Erstellung von Zeitspalten, die bei einer Änderung automatisch aktualisiert werden ...

Die Verarbeitung mit embedded SQL hat mehrere Vorteile:
1. auch Programmierer, die kein RPG, COBOL oder JAVA können, sind in der Lage die SQL-Statements zu lesen.
2. Ein großer Teil der Datenbanken-Logik kann in SQL-Views hinterlegt werden. SQL-View haben jedoch keinen Schlüssel und können dafür mit native I/O nur begrenzt eingesetzt werden. Mit embedded SQL wird die Reihenfolge der Datensätze durch eine zusätzliche Order By-Anweisung im Select-Statement vorgegeben.

@Baldur: Wo steht das mit der Blockgröße von 64K versus 4K.

Ich vermute Du meinst die PageSize von SQL Indices, die per Default mit 64K angelegt wird, im Vergleich zu DDS beschriebenen logischen Dateien, die per Default eine PageSize von 8K haben.

Vielleicht noch eine Randbemerkung:
Wenn nur ein einzelner Datensatz gelesen werden muss, ist native I/O immer noch um einiges schneller als SQL. SQL wird dann schnell wenn die Datensätze geblockt verarbeitet werden können.

Birgitta

**Fuerchau** · 14-11-08, 16:54

Das mit der Prüfung beim Lesen von DDS-Dateien halte ich auch für ein Gerücht!

Sowohl beim Schreiben als auch beim Lesen erfolgt KEINE Prüfung durch die Datenbank.
Die Leseprüfung erfolgt durch den internen RPG-Overhead, der aus dem Dateipuffer in die Variablen überträgt und dabei eben Dezimalfeldfehler auslöst.
Diese Prüfung kann ich aber mittels
CRTRPGPGM IGNDECERR(*YES)
ausschalten. Fehlerhafte Dezimaldaten werden dann zu 0 übersetzt.
Im ILERPG gibts sogar eine H-Bestimmung dazu.

Bei COBOL sieht das da nämlich ganz anders aus. COBOL arbeitet direkt mit den Dateipuffern und bekommt daher auch beim Lesen keine Fehler.
Erst beim Ansprechen der Variableninhalte kommt es zum Dezimalfehler.
Eine Compileroption gibts dafür nicht, jedoch kann ich per
IF FELD IS NUMERIC
...
END-IF
Das Problem umgehen.

Da SQL eben noch eine Schicht zwischen der internen PF und dem Programm ist, gibts bem Select ebenso Dezimalfehler bei ungültigen Daten, die ich aber eben nicht ausschalten kann, ebenso prüft SQL VOR der Ausgabe in die PF eben die richtige Typisierung.

**B.Hauser** · 14-11-08, 18:52

Das mit der Prüfung beim Lesen von DDS-Dateien halte ich auch für ein Gerücht!

Dann würde ich Dir den folgenden Artikel empfehlen:
Modernizing Database Access
The Madness Behind the Methods
By Dan Cruikshank

Birgitta

**BenderD** · 16-11-08, 11:50

Glaube keiner Benchmark, die du nicht selber gefälscht hast.

aktuelle Hardware sollte eine einzelne I/O Operation im Bereich 1 Milli Sekunde (10 ** -6) bewerkstelligen.

auf aktueller Hardware dauert eine CPU Operation in der Größenordnung 0,5 * 10 ** -8 Sec. (entspricht ca. 500 Mips)

das heißt eine I/O Operation dauert solange wie 500 Prozessor Anweisungen. Die oben genannten Zahlen basieren auf Schätzungen und das Verhältnis ist eher größer als kleiner (sprich I/O eher langsamer, CPU eher schneller)

Nun sind an gemessenen Zahlen eine Unsumme an Faktoren beteiligt und wenn ich mal unterstelle, dass das mit der Prüferei alles so stimmt, wobei ich zu Baldur tendiere und mir kaum vorstellen kann, dass Entwickler eines ISAM Dateisystems (entspricht DDS) so blöd sind Tod und Teufel zu prüfen und dann die Ergebnisse zu ignorieren, dann bleibt für mich immer noch klar erkennbar, dass an den Messungen in dem Artikel andere Faktoren beteiligt waren oder die Messung ein Fake ist (wie seinerzeit die Java Benchmark "Towers of Hanoi" die für den CRTJVAPGM sagenhafte Verbesserungen gegenüber ohne aufwies).

Selbst die blanken Messergebnisse legen andere Deutungen nahe, was eine gründliche Untersuchung überprüfen müsste; So ist der CPU Verbrauch in den Charts auf Seite 5 und 6 bei beiden Varianten gleich, die waits sind mehr und der Rest, (der im wesentlichen zu Lasten von I/O geht) nimmt ebenfalls zu. Im Klartext: DDS erstellte wiesen mehr waits und mehr synchronous I/O auf, was sich viel eher aus einem anderem Blockungsverhalten in Verbindung mit pre Fetching und caching erklären lässt.

D*B