View Full Version : RRN trotz RGZPFM merken
Dann ist die Aufgabenstellung mir noch nicht klar.
Wenn du eine Beziehung A zu C und B zu C aufbauen willst, musst du doch bereits eine Beziehung A zu B herstellen können.
In diesem Fall reicht einfach eine View per SQL die die beiden Tabellen verbindet.
Ebenso ist mit den weiteren Tabellen zu verfahren.
Mit Verketten hat das ja nichts zu tun.
Genau das ist mein Problem. Zwischen A, B und den Restlichen gibt es keinen Bezug.
Dann wirst du auch mit Datei C nicht weiterkommen oder soll dieser Bezug manuell hergestellt werden?
Dann frage dich zuerst, welche der vielen Dateien ggf. als Primärdatei verwendet werden kann.
Dann erstelle Datei C mit den Primärschlüsseln (immer schön einzelne Felder) und ergänze dann die zusätzlichen Felder aus den anderen Dateien.
Über die Primärdatei kopierst du schon mal die Primärschlüssel, dann benötigst du nur noch ein Erfassungsprogramm, mit dessen Hilfe ein Begabter die Schlüssel aus den anderen Dateien dazu dichtet.
Tut mir leid, wenn das etwas gehässig klingt, aber programmtechnisch gibt es da keine Lösung.
Das sind einfach zu viele Schlüssel.
Dankeschön für deine Vorschläge und Zeit!
Ich denke, wir müssen da noch mal überlegen.
Also eine Datei, die alle Datensätze aller Dateien enthält und in der jeder Datensatz weiß, wo er herkommt?
Dann sollte man sich doch noch mal überlegen, was denn mit dieser Datei C tatsächlich erreicht werden soll und wieso man Beziehungen erzwingen will, die gar nicht vorhanden sind.
Letztlich kann ich auch eine verwandschaftliche Beziehung mit dir herstellen, wenn ich bis in die Zeit der Auswanderung des Cro-Magnon aus Afrika zurückgehe.
Aber ob du das willst?
@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.
@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
08-05-17, 16:38
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
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.