Return ILE RPG

[Squall]

Ist SQL denn nicht schneller als das Lesen mithilfe von Setll, read und Co.?

Die Frage für mich wäre jetzt noch:

Ich habe zb 3 Tabellen:

TABA       TABB      TABC
NAME       FNAME     ONAME
           NNAME     Wert 

Hierbei gilt die 1. Felder sind als "K" Felder definiert. NNAME ist ein normales Feld. Name = NNAME udn FNAME = ONAME. Ich will an den Wert und habe nur NAME. Ein Setll scheitert doch da NNAME kein Keyfield ist. Dh. ich muss die ganze Datei durchlesen und mit if überprüfen. Oder geht das noch anders?

Martin

[Fuerchau]

By Design: Für jeden Zugriff einen Index (LF), gilt übrigens auch für SQL, denn der ist dann noch schneller.

[Squall]

By Design: Für jeden Zugriff einen Index (LF), gilt übrigens auch für SQL, denn der ist dann noch schneller.

Ich werds erstmal über ein LF mit Joins probieren. Dann hab ich im Grunde auch nur eine Datei zum Lesen.

[B.Hauser]

Ich werds erstmal über ein LF mit Joins probieren. Dann hab ich im Grunde auch nur eine Datei zum Lesen.

Wenn Du dabei an DDS beschriebene logische join files denkst, vergiss es!
Wenn Du dabei an SQL views denkst ist das in Ordnung.

Zur näheren Erklärung. SQL verwendet immer direkt die physischen Dateien. Zugriffs-Wege (geschlüsselte logische Dateien und SQL Indices) werden intern benutzt um möglichst schnell auf die Daten zugreifen zu können. Welcher Zugriffsweg verwendet wird, entscheidet der Query Optimizer.

SQL Indices können im Gegensatz zu geschlüsselten logischen Dateien nicht in einem SQL-Statement angegeben werden.
Werden DDS beschriebene logische Dateien angegeben, löst der Optimizer die logischen Dateien auf, d.h. das SQL-Statement wird basierend auf den physischen Dateien mit der Feld-Auswahl, Join-Anweisungen und Select/Omit-Anweisungen (als Where-Bedingungen) neu geschrieben.
Erst im Anschluss ermittelt der Optimizer die optimalen Zugriff-Wege und zwar einen eigenen für jede verknüpfte physische Datei (Tabelle).

Die Auflösung der DDS-beschriebenen Dateien kann nur durch die alte (classic) Query Engine (CQE= erfolgen. Allein das Rerouting von der neuen SQL-Query-Engine (SQE) zur CQE kann bis zu 10% Performance-Einbußen mit sich bringen.

Abfragen die durch die SQE verarbeitet werden, sind z.T. wesentlich schneller als Abfragen, die durch die CQE verarbeitet werden.

Ausserdem wurden in den letzten Releasen Neuerungen in SQL eingeführt, z.B. EXCEPT, INTERSECT, OLAP-Ranking-Funktionen und rekusrive Abfragen, die NUR durch die SQE verarbeitet werden können.

Birgitta

[Squall]

Wenn Du dabei an DDS beschriebene logische join files denkst, vergiss es!
Wenn Du dabei an SQL views denkst ist das in Ordnung.

Zur näheren Erklärung. SQL verwendet immer direkt die physischen Dateien. Zugriffs-Wege (geschlüsselte logische Dateien und SQL Indices) werden intern benutzt um möglichst schnell auf die Daten zugreifen zu können. Welcher Zugriffsweg verwendet wird, entscheidet der Query Optimizer.

SQL Indices können im Gegensatz zu geschlüsselten logischen Dateien nicht in einem SQL-Statement angegeben werden.
Werden DDS beschriebene logische Dateien angegeben, löst der Optimizer die logischen Dateien auf, d.h. das SQL-Statement wird basierend auf den physischen Dateien mit der Feld-Auswahl, Join-Anweisungen und Select/Omit-Anweisungen (als Where-Bedingungen) neu geschrieben.
Erst im Anschluss ermittelt der Optimizer die optimalen Zugriff-Wege und zwar einen eigenen für jede verknüpfte physische Datei (Tabelle).

Die Auflösung der DDS-beschriebenen Dateien kann nur durch die alte (classic) Query Engine (CQE= erfolgen. Allein das Rerouting von der neuen SQL-Query-Engine (SQE) zur CQE kann bis zu 10% Performance-Einbußen mit sich bringen.

Abfragen die durch die SQE verarbeitet werden, sind z.T. wesentlich schneller als Abfragen, die durch die CQE verarbeitet werden.

Ausserdem wurden in den letzten Releasen Neuerungen in SQL eingeführt, z.B. EXCEPT, INTERSECT, OLAP-Ranking-Funktionen und rekusrive Abfragen, die NUR durch die SQE verarbeitet werden können.

Birgitta

Ich wollte über read setll etc dieses LF lesen. So würde ich es mir sparen 3-4 Dateien einzeln zu lesen. Soweit ich das oben verstanden habe sollte man nur mit SQL nicht auf diese LFs gehen, da man starke Performanceeinbußen hinnehmen müsste. Aber steht dem lesen über read etwas im Wege?

Martin

[Fuerchau]

Nein, natürlich nicht.
SQL interessiert sich nur indirekt für LF's und optimiert da manchmal selbstständig herum.
Ich habe es leider schon des öfteren erlebt, dass ich eine Join-LF mit Schlüssel performant per SETLL/READ verarbeiten kann, aber sobald ich mit SQL daran gehe habe ich Performance-Engpässe.
Klar bilde ich die Join als SQL-View nach, aber die kann keinen Index wie die Join-LF haben. Leider kommt der Optimizer nicht zu dem Ergebnis den ich mit der Join-LF vorschlage.
Was bleibt ?
Verarbeitung halt über SETLL/READ, da SQL hier einfach streikt.

Was deine Verarbeitung über F-Bestimmungen angeht, so scheinst du da eben keine Laufzeitlizenz für SQL zu benötigen.
Die F-Bestimmungen sind eben was speziefisches der AS/400 (naja RPG) und werden intern glaube ich über DDM-Dienst aufgelöst.

[Squall]

Ok danke.

Martin .

[BenderD]

@ Birgitta,

ich kann deine Begeisterung für die neue Query Engine ü b e r h a u p t
nicht teilen, die hat einen Hang zu full table scans, insbesondere bei vorhandenem parallel Database Feature und trifft teilweise katastrophale Entscheidungen. Beim Join von einer Table mit 3 Sätzen mit einer anderen mit 490 Millionen Sätzen über den Mandanten Key (dec 3 0) stellt sie den Boliden links hin und macht dort einen full table scan (um 35 Millionen Treffer zu finden) damit sie die drei Sätze nach Index verarbeiten kann; selbst wenn ich von den 3 Sätzen 2 lösche, wird dieser Satz per Index verarbeitet!?!?
BTW. hast du schon mal gesehen, dass ein EVI verwendet wird??? ich nicht!!! und die Empfehlung selbigen vor updates zu löschen und hinterher wieder zu erstellen - rührend.

mfg

Dieter Bender

Wenn Du dabei an DDS beschriebene logische join files denkst, vergiss es!
Wenn Du dabei an SQL views denkst ist das in Ordnung.

Zur näheren Erklärung. SQL verwendet immer direkt die physischen Dateien. Zugriffs-Wege (geschlüsselte logische Dateien und SQL Indices) werden intern benutzt um möglichst schnell auf die Daten zugreifen zu können. Welcher Zugriffsweg verwendet wird, entscheidet der Query Optimizer.

SQL Indices können im Gegensatz zu geschlüsselten logischen Dateien nicht in einem SQL-Statement angegeben werden.
Werden DDS beschriebene logische Dateien angegeben, löst der Optimizer die logischen Dateien auf, d.h. das SQL-Statement wird basierend auf den physischen Dateien mit der Feld-Auswahl, Join-Anweisungen und Select/Omit-Anweisungen (als Where-Bedingungen) neu geschrieben.
Erst im Anschluss ermittelt der Optimizer die optimalen Zugriff-Wege und zwar einen eigenen für jede verknüpfte physische Datei (Tabelle).

Die Auflösung der DDS-beschriebenen Dateien kann nur durch die alte (classic) Query Engine (CQE= erfolgen. Allein das Rerouting von der neuen SQL-Query-Engine (SQE) zur CQE kann bis zu 10% Performance-Einbußen mit sich bringen.

Abfragen die durch die SQE verarbeitet werden, sind z.T. wesentlich schneller als Abfragen, die durch die CQE verarbeitet werden.

Ausserdem wurden in den letzten Releasen Neuerungen in SQL eingeführt, z.B. EXCEPT, INTERSECT, OLAP-Ranking-Funktionen und rekusrive Abfragen, die NUR durch die SQE verarbeitet werden können.

Birgitta