LF, View, Index

[Andreas_Prouza]

Hallo Dietlinde,

Was für eine Fehlermeldung liefert er dir beim erstellen des Index:
create index Lib/indexname on Datei
dec(substr(key, 1, 7), 7, 0) as NR,
dec(substr(Keyxx, 8, 1), 1, 0) as N2

Normal kann man schon beim Index die Spalten manipulieren.
Ich kann mir vorstellen, dass du hier beim Substring einen Konvertierungsfehler haben kannst, wenn der Wert NICHT Nummerisch ist.

lg Andreas

[Fuerchau]

Blödes Konzept aber:

Auf Views kannman keinen Index erstellen, aber man kann einen berechneten Index incl. Where auf die PF erstellen.

Dies nützt aber nur etwas, wenn die Whereklausel genaue diese Bedingung des Index auch verwendet.
Also der Index wird mit "...dec(...) " erstellt, dann muss die Whereklausel auch "... where dec(...) .." enthalten.

Dein Hauptproblem ist allerdings die Konvertierung des Keys, wenn die Struktur für alle Konvertierungen nicht identisch ist.
Seit V6R1 hat sich die SQL-Logik leider etwas geändert:

select dec(f1, 5, 0) from myfile where key = 'D1';

Die Umwandlung in dec() wird vor der Prüfung der Whereklausel durchgeführt!
K.a. warum das so ist. D.h., wenn die Konvertierung fehlschlägt wird die Whereklausel nicht mehr ausgeführt. Du musst also in deine Umwandlung eine zusätzliche Prüfung auf den Inhalt einbauen.
Performant wird das dann nicht mehr.

M.a.W.: Dein Konzept funktioniert nur dann, wenn die Struktur der variablen Schlüssel identisch ist.
Da das wohl nicht gewährleistet ist, hast du da schlechte Karten.

Alternativ kannst du Service-Programme bauen, die die Zugriffe entsprechend gestalten. Die Programme dürfen dann nur über die Services zugreifen.

[dibe]

@Andreas

create index Lib/indexname on Datei
dec(substr(key, 1, 7), 7, 0) as NR,
dec(substr(Key, 8, 1), 1, 0) as N2

SQL0104
Nachricht . . . : Token DEC ungültig. Gültige Token: IN NOT KEEP NONE PAGE
UNIT WITH ALLOW DEFER USING DEFINE EXTEND.


@Herr Fuerchau

um z.b. 100erte von Maschinen Daten zu historisieren von dehnen sich 1/2 sekündlich 0-3 ändern, wäre es Wahnsinn
a) je Zeittakt den gesammten Satz mit > 1000 Byte zu speichern
b) Je Feld eine eigene Historie zu führen
c) je Produktlinie (die bestimmt den key) eine Historie zu führen
d) die Kombination aus b und c

Da hat sich dieses Konzep sehr gut bewährt.
Und solange wir mit RPG arbeiten, sind die genauen zeilichen Abläufe sehr einfach und schnell dar zu stellen.

Auch in unsere DSGVO Verarbeitung ist dies bisher ohne Probleme, schnell und performant, mit RPGLE.

Leider zieht bei uns die Form der Modernisierung ein, die alles alte schlecht findet. Es soll nur noch mit SQL gearbeitet werden und die Schwächen vom SQL aber auch Java + (teilweise) Php werden als Designfehler der > 40 Jahre alten Anwendung verkauft.
Diese gibt es sicherlich. Aber an ganz anderen Stellen in der Verarbeitung.

Ich werde mich dann also dafür einsetzen, das wir weiter "ALT" und funktionierend mit RPG arbeiten anstatt 'Modern' und dafür alles umstellen.

Vllt hat ja Andreas noch einen Tipp

Vielen Dank an Euch
Dietlinde Beck

[Fuerchau]

Wie wäre es, SQL mit einer Table-Function und Proceduren zu erweitern?
Dies sollte doch konzeptionell ebenso umsetzbar sein.

In der Microsoft-Fraktion wird auch gerne empfohlen, für alles und jedes eine SP (Strored procedure) zu verwenden, da dies ja native in der DB läuft und somit von Wartezeiten im (entfernten) Client unabhängig zu sein.

https://www.ibm.com/docs/en/i/7.1?to...considerations

Auch für Insert/Updates/Deletes kann man genauso ein SQL-Call o.ä. durchführen.
Konzeptionell handelt es sich daher um SQL-Erweiterungen, die doch ebenso zulässig sein sollten.

[B.Hauser]

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?

[B.Hauser]

Leider zieht bei uns die Form der Modernisierung ein, die alles alte schlecht findet. Es soll nur noch mit SQL gearbeitet werden und die Schwächen vom SQL aber auch Java + (teilweise) Php werden als Designfehler der > 40 Jahre alten Anwendung verkauft.

Nicht alles was früher geklappt hat war auch gut! Da könnte man tausende von Beispielen nennen.
... allerdings habt Ihr m.E. mit der Modernisierung an der falschen Stelle angefangen.
Ihr hättet zuerst die Dateien/Tabellen bereinigen sollen.
So etwas geht und wenn gewährleistet werden soll, dass auch die alten Schinken noch weiterhin laufen, kann man in 2 Schritten vorgehen:
1. Zusätzliche Spalten in denen die aufgedrößelten Werte stehen
2. ein zusätzlicher Trigger, der die alten und neuen Spalten beim Ändern der Schlüssel-Werte oder beim Einfügen der Schlüssel-Wert beim Insert automatisch gerade zieht.

Dann könnt Ihr Zugriffswege über die neuen Spalten legen. Die alten Programme funktionieren wie bisher und in den neuen Programmen wird nur noch auf die neuen Spalten zugegriffen.
... dann könnt Ihr gemütlich alles umstellen und zum Zeitpunkt x, wenn kein Zugriff mehr auf die alten Spalten erfolgt können die alten Spalten, sowie die Trigger entfernt werden.

Für die JOINs wäre es allerdings besser wenn in den Tabellen mit künstlichen Schlüssel (z.B. Identity Columns) gearbeitet wird, die auch in den abh. Dateien integriert werden.
Auch hier muss man natürlich Zwischenschritte machen um sicherzustellen, dass die Anwendung weiterläuft. Wenn die Joins jedoch in entsprechenden Views hinterlegt werden und die Zugriffe nur noch über diese Views erfolgen, kann man auch hier nach und nach (richtig) umstellen. Es muss lediglich die Verknüpfung in der View angepasst werden. Eine Kompilierung ist nicht erforderlich, so lange die Spalten gezielt ausgewählt wurden.
Dem Benutzer/Programmierer, der die View verwendet ist es egal ob und wie die Verknüpfung erfolgt, Hauptsache er bekommt die richtigen Daten.