-
LF, View, Index
Guten Tag
Wir haben im Rahmen der DSGVO eine 'Universal Datei' erstellt.
Dateiname
Key
Feld
Wert
herkunft
Grund
Datum
....
In der Datei steht im Dateiname z.b.
Mandant
Kunde
Ansprechpartner
...
das Feld Key beinhaltet den Key des Datensatzes in der Datei also z.B.
DEB1234567
DIV3317877
CRD1144788
im Mandantenstamm ist der key in 2 Feldern
Art = DEB und
Nr. = 1234567
Viele Pgmme arbeiten mit dieser einen Datei.
Nun habe ich View's erstetellt, JE Dateinamen, die den Key Typgerecht wieder in Einzelfelder zerlegt.
Aber ich kann keinen Index auf die View legen!
und ein
create index Lib/indexname on Datei
dec(substr(key, 1, 7), 7, 0) as NR,
dec(substr(Keyxx, 8, 1), 1, 0) as N2
geht auch nicht.
Wie bekomme ich die 'schnelle' Zugriffe.
Vielen Dank
Dietlinde Beck
-
... works as designed.
D*B ,erschüttert, wie man auf solche Ideen kommen kann!
-
Ein Index kann immer nur auf eine einzige Physische Datei oder Tabelle gelegt werden!
Wie sieht denn Deine View aus?
Wie werden die Tabellen verknüpft?
Abh. von dieser JOIN-Anweisung kannst Du überlegen, wie die Indices auf den einzelnen Tabellen/physischen Dateien aussehen müssen.
-
@Herr Bender
diese Form hat sich seid mehreren Jahren in mehreren Anwendungen für dynamische Sammelbecken bewährt. Nicht erst seid der DSGVO. Aber leider müssen wir nun gezielt, d.h. über eine Verknüpfung zur orginal Datei auf die Daten zugreifen.
@Frau Hauser
Die view's haben keine join.
Die View's:
select f1, f2, dec(substr(key, 1, 7), 7, 0) as NR,
dec(substr(Keyxx, 8, 1), 1, 0) as N2, f5, f6, f7 from datei where f1 = 'DATEINAME'
oder
select f1, f2, substr(key, 1, 3) as Art,
dec(substr(Keyxx, 4, 7), 7, 0) as Nr, f5, f6, f7 from datei where f1 = 'DATEINAME'
Jetz überlege ich, ob ich zusätzlich VIEW's auf die Basidateien lege, und dort ein Feld generiere, das den Key in meiner Sammeldatei darstellt.
Aber eigendlich ist das falsch herum
Schade das SQL das nicht kann
DiBe
-
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
-
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.
-
@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
-
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.
-
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.
-
Zitat von dibe
Die View's:
select f1, f2, dec(substr(key, 1, 7), 7, 0) as NR,
dec(substr(Keyxx, 8, 1), 1, 0) as N2, f5, f6, f7 from datei where f1 = 'DATEINAME'
oder
select f1, f2, substr(key, 1, 3) as Art,
dec(substr(Keyxx, 4, 7), 7, 0) as Nr, f5, f6, f7 from datei where f1 = 'DATEINAME'
Jetz überlege ich, ob ich zusätzlich VIEW's auf die Basidateien lege, und dort ein Feld generiere, das den Key in meiner Sammeldatei darstellt.
... die verhuddelten Keyfeder für die Basisdatei in eine view zu packen, wird wohl wenig helfen, Nachhaltiger wäre es, der Basisdatei einen key zu verpassen (könnte ein generierter sein) und eine view draufzustellen, die diesen weglässt (kann auch eine DDS erstellte sein, dann merken vorhandene Altanwendungen nix davon.
Die Historiendatei hätte dann einen compound key aus Dateiname und dem neuen Kunstkey.
D*B
-
Zitat von Fuerchau
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?
-
Zitat von BenderD
...
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
Similar Threads
-
By dibe in forum IBM i Hauptforum
Antworten: 14
Letzter Beitrag: 01-07-18, 16:27
-
By malzusrex in forum NEWSboard Programmierung
Antworten: 9
Letzter Beitrag: 19-10-16, 18:53
-
By ExAzubi in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 19-07-16, 11:44
-
By woodstock99 in forum NEWSboard Programmierung
Antworten: 31
Letzter Beitrag: 18-03-15, 13:29
-
By KingofKning in forum NEWSboard Programmierung
Antworten: 6
Letzter Beitrag: 29-12-14, 12:01
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks