View Full Version : LF, View, Index
Wie wäre es, SQL mit einer Table-Function und Proceduren zu erweitern?
Um eine Tabellen-Funktion oder eine Stored Procedure, die Result-Sets ausgibt, performant ausführen zu können sind ebenfalls die richtigen Zugriffswege erforderlich.
Stored Procedures können nicht in SELECT-Statements angegeben werden.
UDTFs mit mehr als einem Statement sind für den Query-Optimizer BLACK-Boxes, werden unahb. vom endgültigen SELECT-Statement optimiert (was manchmal dann eben nicht so optimal ist!)
... und solange man alles mit einem SQL-Statement erschlagen kann, warum überhaupt eine UDTF erstellen, wenn man stattdessen eine View verwenden kann?
...
Die Historiendatei hätte dann einen compound key aus Dateiname und dem neuen Kunstkey.
D*B
Ja, so einen automatisch generierten 'Kunstkey' haben wir damals überlegt.
Da wir aber noch mit DDS Dateien und RPG Write arbeiten hätte ein Trigger diese Nr vergeben müssen.
Das wiederum hätte die Anwendung verlangsamt (Lfnr lesen, erhöhen, speichern) bei mehreren 100 Anwendern
Ich geben gerne zu, zu diesem Thema (automatisch vergebener Key in einer PF) nicht viel zu wissen.
Literatur / Infos nehme ich gerne!
Was ich aber weis ist, das das nicht nebenbei mal eben ein zu führen ist.
RPG kann es. Der Aufwand ist überschaubar, lesbar ist es allemal.
Vielen Dank
Dibe
Such mal nach Identity Columns:https://www.ibm.com/docs/en/i/7.4?topic=language-creating-altering-identity-column
Solange Du über die Identity Column einen Primary Key Constraint (oder einen Unique Key) legst, und dem System keinen Cycle erlaubst und den Zähler nicht manuell zurücksetzst, wird die Identity Column beim Insert (aber auch beim RPG write) automatisch (ohne Trigger) generiert.
... und Identity columns können mal eben so eingeführt werden! Der Aufwand ist nicht größer als wenn in einer Datei ein neues Feld eingefügt oder ein vorhandenes Feld geändert wird.
... und Identity columns können mal eben so eingeführt werden! Der Aufwand ist nicht größer als wenn in einer Datei ein neues Feld eingefügt oder ein vorhandenes Feld geändert wird.
... eigentlich ist er kleiner, wenn man das so einrichtet, dass am Ende der Aktion eine DDS-LF mit dem ursprünglichen Namen der PF, gleichen Feldern und gleicher Format-ID existiert.
D*B
PS: was macht ihr denn mit RPG RLA, was mit SQL nicht geht? Vielleicht macht ihr da ja was auf dem 2.-besten Weg!
Danke für diese Information!
So wie sich das liest muß die Datei aber SQL beschrieben sein.
oder geht ein
Alter Table add colum<code class="language-plaintext hljs">
ORDERNO SMALLINT NOT NULL</code><code class="language-plaintext hljs">
GENERATED ALWAYS AS IDENTITY </code><code class="language-plaintext hljs"></code><code class="language-plaintext hljs">
(START WITH 500 </code><code class="language-plaintext hljs">
INCREMENT BY 1</code><code class="language-plaintext hljs">
CYCLE)</code>
Wenn ich alles auf SQL basiere Dateien umstelle, bekomme ich das Satzformat Problem
(obwohl ... ich glaube das kann SQL auch mitlerweile!?)
Und was bedeutet ... dem System keinen Cycle erlaubst ...
Vielen Dank
Dietlinde Beck
... man kann problemlos eine DDS LF auf eine SQL erstellte PF stellen, die dasselbe Format, wie die ersprüngliche PF hat.
Was willst du mit einer Identity von max. 32767 Werten;-)?
Eine Identity dient i.d.R. auch als Primary Key und sollte daher mindestens Integer sein.
Mit Table Functions habe ich bisher keine schlechten Erfahrungen gemacht.
Die IBM baut ja selber dauernd neue für die ganzen Vewaltungs-API's (Service-Views).
Table-Functions und Procedures dienen ja nur zur Verbergung von direkten SQL-Zugriffen und stellen zumindest nach meiner Erfahrung kein Problem dar.
Was das Create Table angeht, so kann man natürlich einen Satzformatnamen angeben, in RPG/LE kann man den aber auch umbenennen.
Aber wie immer in der IBM i-Welt: es gibt 100te Meinungen und 1000de Lösungen;-).
Habe das gerade mal ein wenig probiert,
mit "alter Table" geht das auf DDS beschriebene PF, das ist gut.
Gelöschte Sätze werden mitgezählt, das ist schlecht.
ein RGZPFM nummeriert neu durch, das wäre eine Katastrophe, dann wären ja alle abh. Dateien falsch!
kann man das einstellen?
Habe das gerade mal ein wenig probiert,
mit "alter Table" geht das auf DDS beschriebene PF, das ist gut.
Gelöschte Sätze werden mitgezählt, das ist schlecht.
ein RGZPFM nummeriert neu durch, das wäre eine Katastrophe, dann wären ja alle abh. Dateien falsch!
kann man das einstellen?
Lass das! Spätestens bei der nächsten DDS-Änderung hast Du die Identity vergessen!
Konvertiere die Tabelle nach DDL und füge dann die Spalte hinzu.
Erstelle das SQL Skript über Reverse Engineering (ACS Wizard - Generate SQL oder SQL Stored Procedure GENERATE_SQL), achte darauf, dass CREATE OR REPLACE TABLE angegeben ist.
Führe das SQL Skript aus ... und schon ist die Tabelle konvertiert! Wenn Du nur konvertierst und keine neuen Spalten einfügst brauchst Du noch nicht einmal die RPG-Programme mit Native I/O zu kompilieren.
Aber Achtung: Vor der Konvertierung musst Du sicherstellen, dass Deine physische Datei keine ungültigen numerischen Daten (z.B. *Blanks) enthält, ansonsten gehen Dir Daten verloren.
In der Bibliothek SYSTOOLS gibt es die Funktionen VALIDATE_DATA, VALIDATE_DATA_FILE und VALIDATE_DATA_LIBRARY mit denen Du auf ungültige numerische Werte prüfen kannst. Diese müssen zunächst korrigiert werden.
Alle Daten und abh. Objekte bleiben erhalten und müssen nicht neu erstellt werden.
Andreas_Prouza
04-02-22, 11:57
Ein RGZPFM ändert nicht die Nummer bei einer Identiy Spalte.
ei Commit-Steuerung, wenn neu erstellte Sätze doch wieder mit Rollback entfernt werden, entstehen ebenfalls Lücken im Nummernkreis.
Das ist aber völlig egal und hat auch niemandem zu interessieren, da die Nummern nicht für eine hübsche Lesbarkeit sondern für Eindeutigkeit und Integrität bei Fremdschlüsseln dienen.
Ich verwende (meistens) sowieso nur noch BIGINT für die ID.
Teilweise haben wir hier noch ein Denkschema von 1980 wo jedes Byte gezählt hat.
Heute erzeugen wir durch dieses Denkschema nur langfristige Probleme, denn von der Performance merkst du da bei den Maschienen keinen Unterschied mehr.