"SQL view create statement" aus DSPFD

[Muchi]

Hallo,

ich möchte das "SQL view create statement" aus dem DSPFD per Programm auslesen. Leider kann man diesen Eintrag nicht per Outfile auslesen. In welcher Tabelle steht denn der Eintrag?

Danke und Gruß,
Michael

[B.Hauser]

Versuch's mal mit der Catalog-View SYSVIEWS in der QSYS2. Da ist zumindest der Name der View, die Bibliothek und das Select-Statement hinterlegt.

Ansonsten kann man auch das API QSQGNDDL verwenden um die SQL-Statements zu generieren.

Birgitta

[Muchi]

Danke. Das API liefert genau die Infos, die ich brauche.

Sind per SQL erstellte Tabellen "schneller" in der Verarbeitung als DDL erstellte Tabellen?

Danke und Gruß,
Michael

[Fuerchau]

Pauschal ja, Birgitta hat da entsprechende Ausführungen schon gepostet.

DDS:
- prüfen der Daten beim Lesen
- keine Prüfung beim Schreiben (Schrott in gepackten Feldern möglich)
- Index auf der PF möglich
- Eingangsfolge mit REUSEDLT(*NO) möglich
- etwas langsamerer Index

SQL:
- prüfen der Daten beim Schreiben (nur gültige Daten)
- keine Prüfung beim Lesen
- Keine Eingangsfolge da REUSEDLT(*YES)
- Kein Index direkt auf der PF
- zusätzlicher Index (ggf.) erforderlich
- bessere Indexperformance

Jetzt kommts halt auf die Anwendung an, was besser ist, wobei neue Anwendung mit SQL auf jeden Fall besser fahren.

[BenderD]

.. häufig kolportiertes Marketing Gesums und Vergleich von Äpfeln mit Birnen. Mit SQL erstellen und mit RLA verarbeiten passt ebenso wenig wie mit DDS erstellen und mit SQL verarbeiten.
Wenn man komplett DDS/RLA mit komplett SQL vergleicht gilt:
- SQL prüft generell mehr (übertragung auf Feldebene versus Übertragung von Buffern), das bringt zusätzlichen Overhead und mehr Sicherheit.
- RLA braucht mehr Zugriffspfade und hat damit mehr Overhead beim schreiben
- Mix DDS/SQL/RLA braucht nochmehr Zugriffspfade
- RLA hat die Ressourcenschondenderen Zugriffsmethoden
- SQL hat bei korrekter Verwendung (grobkörnige Zugriffe) das wesentlich bessere caching Verhalten
- SQL Programmierung ist bei korrektem Einsatz deutlich einfacher

Summa Summarum: auf neuerer Hardware mit entsprechendem Ressourcen Überschuss ist komplett SQL klar im Vorteil.

RLA/DDS/SQL Mix ist nur als Übergangsszenario vertretbar.

SQL statt RLA bei gleicher Programmstruktur bringt bestenfalls nix.

Reine Umstellung der Tabellen und weiter so wie bisher bringt ebenfalls besten Falls nix.

D*B

Pauschal ja, Birgitta hat da entsprechende Ausführungen schon gepostet.

DDS:
- prüfen der Daten beim Lesen
- keine Prüfung beim Schreiben (Schrott in gepackten Feldern möglich)
- Index auf der PF möglich
- Eingangsfolge mit REUSEDLT(*NO) möglich
- etwas langsamerer Index

SQL:
- prüfen der Daten beim Schreiben (nur gültige Daten)
- keine Prüfung beim Lesen
- Keine Eingangsfolge da REUSEDLT(*YES)
- Kein Index direkt auf der PF
- zusätzlicher Index (ggf.) erforderlich
- bessere Indexperformance

Jetzt kommts halt auf die Anwendung an, was besser ist, wobei neue Anwendung mit SQL auf jeden Fall besser fahren.