SQL Update

[B.Hauser]

meine aussage bzgl. der geschwindigkeit bezog sich nur auf den zugriff mit sql auf sql-tabellen vs. dds-tabellen..

Das liegt daran, dass beim Schreiben in SQL Tabellen geprüft wird, ob der angekommene Inhalt gültig ist, während beim Lesen aus SQL-Tabellen keine Gültigkeitsprüfung erfolgt. Bei DDS beschriebenen Dateien erfolgt die Gültigkeitsprüfung erst beim Lesen, während jeder Schrott in die Dateien geschrieben werden kann. Dadurch ist das Lesen aus SQL Tabellen (etwas) schneller als das Lesen aus DDS beschriebenen Dateien, während das Schreiben (etwas) langsamer ist.

dass rpg dds-tabellen oft schneller verarbeiten kann als über sql ist klar...

RPG kann zumindest bei der ersten Ausführung Dateien (unabhängig ob DDS oder SQL) schneller verarbeiten als SQL, da RPG in RPG ein Zugriffsweg vorgegeben wird (F-Bestimmungen) währen SQL grundsätzlich optimiert auch und vorallem dann wenn eine DDS beschriebene logische Datei angegeben wird.

wir haben in der firma auch oft probleme, wenn via sql auf dds-tabellen zugegriffen wird. ändere ich diese auf sql-tabellen, läuft es viel schneller.
denn im ersten fall wird die CQE verwendet und im zweiten die SQE, welche gegenüber der CQE zb auch threads parallel abarbeiten kann.

Es ist ein verbreiteter Irrtum, dass die SQE nur SQL-Tabellen verarbeiten könnte, während alle DDS Dateien von der CQE verarbeitet werden müssen. Die SQE kann DDS beschriebene physische Dateien verarbeiten.

Wird in einem SQL-Statement eine DDS beschriebene logische Datei angegeben, wird das SQL-Statement von der CQE ausgeführt, da die logische Datei aufgelöst wird (Feld-Auswahl, Select/Omit und Joins) und das SQL-Statement basierend auf der physischen Datei oder SQL Tabelle neu geschrieben wird. Dies Auflösung kann nur von der CQE vorgenommen werden (SQE steht schließlich SQL Query Engine).

Liegen auf der physischen Datei (oder SQL Tabelle) logische Dateien mit SELECT/OMIT-Anweisungen, wird auch bei Angabe der physischen Datei die Ausführung des SQL-Statements von der CQE übernommen. Der Grund dafür liegt darin, dass alle vorhandenen Zugriffswege also auch diejeningen, die in DDS beschriebenen logischen Dateien mit SELECT/OMIT hinterlegt sind verwendet werden sollen.

Ändert man in der Abfrage-Options-Datei QAQQINI die Option IGNORE_DERIVED_INDEXES auf *YES (*NO ist Unterlassungswert vor Release 6.1 mit Release 6.1 wurde der Unterlassungswert auf *YES geändert), werden Zugriffswege in DDS-beschriebenen Dateien ignoriert und das SQL-Statement kann von der SQE ausgeführt werden. Im Extremfall kann man sich durch diese Option Zugriffswege unter den Füßen wegziehen, so dass anstatt eines Index Access ein Table Scan oder zumindest eine Table Probe erfolgen muss.

Birgitta