RRN trotz RGZPFM merken

[BenderD]

@Pikachu So in etwa, Sie enthält andere Daten die in keiner Datei vorhanden sind, aber dennoch satzspezifisch.

@Fuerchau In diesem Fall gibt es gar keine Verbindung. Nur den Fall, dass zu jedem Satz etwas gespeichert werden soll. Als hätte man die Tabellen Autos, Häuser, Wasserflaschen und wolle zu jedem den Besitzer und alle vorhergehenden Besitzer festhalten.

... dann gehören diese Dateien um entsprechende Felder erweitert, wenn sie nicht zu externen Anwendungen gehören. Macht man das richtig (View Layer heißt das Zauberwort) ist das sehr einfach! Bei Fremdanwendungen bleibt (leider) nur noch pro Datei eine Erweiterungsdatei anzulegen, die den Schlüssel der verbundenen Datei plus die benötigten Erweiterungen enthält.

D*B

[dschroeder]

Ich gebe auch nochmal meinen Senf dazu: Wenn ich dich richtig verstehe, willst du Zusatzinformationen zu beliebigen Dateien speichern können. Dein Problem ist aber, dass die Dateien keine "genormten" Schlüsselfelder haben?
Wenn das so ist, wäre es doch eine Möglichkeit, die Zusatzinformationsdatei aus 4 Feldern bestehen zu lassen:
1. Dateiname char(10)
2. Key für Datei char(60) oder eben so lang, wie die längste eindeutige Key-Information ist
3. Art der Zusatzinfo char(20)
4. Zusatzinfo char(200)

Wenn deine Datei A z.B. Kunden enthält und der Schlüssel eine 10-stellige Kundennummer ist und du zusätzlich den Geburtstag der Oma des Kunden speichern willst, müsstest du in der Zusatzinfodatei folgendes speichern:
Dateiname = 'A';
Key = %char(kundennummer);
art = 'OMA_GEBURTSTAG';
zusatzinfo = '15.12.1927';

Wenn du die Tabellen später miteinander verknüpfen wills, muss du natürlich abhängig vom Dateinamen die Verknüfungszeichenfolge aufbauen.

Dieter

[Fuerchau]

Das sind dann irgendwann so Dateien, die mit SQL kaum bis gar nicht mehr auswertbar sind.
Hier muss ich Dieter recht geben, dass man zu jeder betroffenen Datei eine Zusatzdatei mit den Schlüsselfeldern sowie den benötigten Zusatzinformationen anlegt.
Eine Sammeldatei für alles mögliche oder auch unmögliche, macht es dann später ebenso unmöglich überhaupt noch etwas sinnvoll damit anzufangen.

Man muss auch mal an die Zukunft denken, wenn man Auswertungen, Web-Anwendungen o.ä. erstellen will und die Clientprogrammierer, die dann nur mit SQL an die Daten kommen, die Hände über den Kopf schlagen und solche Projekte dann an solchen Datenmodellen scheitern.

Treibe lieber jetzt den Aufwand, das Datenmodell entsprechend aufzubauen, das dann SQL-konform und zukunftsorientiert ist. Das Zeitalter der Satzarten-Verarbeitung ist doch weitestgehend mit der Einführung der Festplatte verschwunden.

[dschroeder]

Das sind dann irgendwann so Dateien, die mit SQL kaum bis gar nicht mehr auswertbar sind.
Hier muss ich Dieter recht geben, dass man zu jeder betroffenen Datei eine Zusatzdatei mit den Schlüsselfeldern sowie den benötigten Zusatzinformationen anlegt.
Eine Sammeldatei für alles mögliche oder auch unmögliche, macht es dann später ebenso unmöglich überhaupt noch etwas sinnvoll damit anzufangen.

Man muss auch mal an die Zukunft denken, wenn man Auswertungen, Web-Anwendungen o.ä. erstellen will und die Clientprogrammierer, die dann nur mit SQL an die Daten kommen, die Hände über den Kopf schlagen und solche Projekte dann an solchen Datenmodellen scheitern.

Treibe lieber jetzt den Aufwand, das Datenmodell entsprechend aufzubauen, das dann SQL-konform und zukunftsorientiert ist. Das Zeitalter der Satzarten-Verarbeitung ist doch weitestgehend mit der Einführung der Festplatte verschwunden.

Da bin ich voll bei dir. Wir haben auch ein paar von diesen Sammeldateien, die ich heute lieber nicht mehr hätte. Ich wollte nur sagen, dass so etwas auch geht, wenn man denn unbedingt mit einer Datei arbeiten möchte.

[Fuerchau]

In solchen Fällen (habe ich aus einem anderen Projekt) bieten sich doch hochflexible XML-Dateien an. Hier kann man beliebig tief schachteln und alles in in Tera-BLOB packen.
Viel Spaß dann beim ver- und bearbeiten.

Solche Konzepte gibt es z.T. wirklich!

[BenderD]

... mein Hauptproblem mit solchen divers (pervers) Dateien ist, dass die nicht mit den zugehörigen Daten in einem join dargestellt werden können.

D*B

[dholtmann]

Ich gebe auch nochmal meinen Senf dazu: Wenn ich dich richtig verstehe, willst du Zusatzinformationen zu beliebigen Dateien speichern können. Dein Problem ist aber, dass die Dateien keine "genormten" Schlüsselfelder haben?
Wenn das so ist, wäre es doch eine Möglichkeit, die Zusatzinformationsdatei aus 4 Feldern bestehen zu lassen:
1. Dateiname char(10)
2. Key für Datei char(60) oder eben so lang, wie die längste eindeutige Key-Information ist
3. Art der Zusatzinfo char(20)
4. Zusatzinfo char(200)

Wenn deine Datei A z.B. Kunden enthält und der Schlüssel eine 10-stellige Kundennummer ist und du zusätzlich den Geburtstag der Oma des Kunden speichern willst, müsstest du in der Zusatzinfodatei folgendes speichern:
Dateiname = 'A';
Key = %char(kundennummer);
art = 'OMA_GEBURTSTAG';
zusatzinfo = '15.12.1927';

Wenn du die Tabellen später miteinander verknüpfen wills, muss du natürlich abhängig vom Dateinamen die Verknüfungszeichenfolge aufbauen.

Dieter

Denke darauf wird es hinaus laufen.
Auslesen geht über Umweg QADBILFI & View mit Hilfe des Dateinamens ja auch.
Hatte halt gehofft über die RRN eine schönere Lösung zu erreichen.

Bei Fremdanwendungen bleibt (leider) nur noch pro Datei eine Erweiterungsdatei anzulegen, die den Schlüssel der verbundenen Datei plus die benötigten Erweiterungen enthält.

Das wäre der richtige Weg, aber bei wer weiß wie viel hundert Dateien kann ich das auch nicht machen.

[BenderD]

... das ganze Konzept humpelt doch an der Aktualisierung dieser Informationen. Der Eingangspunkt mit dem RGZPFM deutet doch schon daraufhin, dass in den originären Informationen Sätze gelöscht werden, mit der Konsequenz, dass dieser Datenmoloch zur Müllhalde verkommt.

Wo siehst Du denn den Aufwand bei einer saubereren Lösung?

D*B

[dholtmann]

Naja das Zumüllen versuchen wir über Trigger zu vermeiden.
Ich sehe das Problem einfach in der Fülle der Dateien, die dann erstellt werden müssten.
Kann nicht mal eben mehrere hundert neue Physische einbauen.

[BenderD]

Kann nicht mal eben mehrere hundert neue Physische einbauen.

... was meinst Du jetzt mit "einbauen". Du brauchst doch dann ohnehin für jede Datei einen Trigger, Logik für die Verhuddelung des Keys, Logik für die Enthuddelung der angehängten Information und irgendwoher müssen dann die anzuhängenden Daten ja auch kommen.

D*B

[dholtmann]

Meinte mehr "anlegen".
Der Trigger auf eine der bestehenden Dateien löst aus, ermittelt anhand des Dateinamens die Keyfelder, kettet diese zusammen und schreibt bzw. löscht damit den Satz der neuen Datei.
Anzeige des Satzes der neuen Datei erfolgt nach gleichem Prinzip.
So der Ansatz bisher. Da dürfte dann nichts Dateispezifisches dabei sein.

[BenderD]

... und was soll der dann schreiben?