Datenbankdesign-Problem

[Forumsgast]

Hallo zusammen,

ich werde dieses Datenbank-Design zwar nicht in MySQL realisieren, sondern unter Oracle, aber vom Design her sollte es ja ähnlich sein.

Folgende Problemstellung:

Ich soll auf Daten aus zwei verschiedenen Tabellen referenzieren. Eine dieser beiden Tabellen ist statisch (also darf nicht editiert werden), die andere Tabelle enthält selbst erstellte Daten und darf editiert werden.

Die statische Tabelle hat eine 11-stellige Zeichenfolge als PrimaryKey, die editierbare hat einen Number-Wert ( in MySQL INT(9) ).

Jetzt stellt sich für mich die Frage, wie ich bereits in der Datenbank die referenzielle Integrität sicherstellen kann, dass auch der richtige Datensatz ausgelesen wird.

Ich hoffe, jmd. kann mir einen Denkanstoß geben.

Hier nochmal ein Beispiel:

Tabelle 1:
-------------
FK Person: INT(11)


Person_1: [statisch]
------------
PK Id : VARCHAR(11)
Name : VARCHAR(50)

Person_2: [editierbar]
------------
PK Id: INT(11)
Name: VARCHAR(50)



Danke

[Forumsgast]

So ganz verstehe ich nicht was du machen möchtest. Was ist denn in Tabelle 1?
PK Id von Person_1 soll sicher INT(11) sein und PK Id von Person_2 INT(9), richtig?
Wer verknüpft die Einträge der beiden Personen Tabellen, wenn Person_1 PK Id 11 Stellen hat und diese nutzt, Person_2 PK Id aber nur 9?

Vielleicht beschreibst du kurz das komplette drumherum.

[Forumsgast]

Hi Zerling,

also .. wollte das komplette drumherum eigentlich vermeiden, aber wenn es nicht anders geht:

Es dreht sich um folgendes:

Ich bekomme einen festen Datenbestand mit Daten (in diesem Fall Banken: ca. 85.000 Einträge) vorgegeben. Diese sind mit einem 11-stelligen Buchstaben-Code (--> VARCHAR) als PrimaryKey versehen. Diese Daten sollen für den späteren Anwender zwar zu sehen, aber nicht editierbar sein. Es sollen auch keine weiteren Einträge in diese Tabelle gemacht werden können, weil es sich hier um offiziell herausgegebene Daten handelt.

Die späteren Anwender haben aber angefordert, bei Bedarf weitere Einträge zu dieser Liste hinzuzufügen, da nicht alle Geschäftspartner in der offiziellen Liste mit der eigenen Firmierung ( evtl. durch eine andere Bank vertreten ) auftauchen.

Somit habe ich zwei Tabellen ( eine editierbare und eine feste ). Aber in einer anderen Tabelle will ich auf einen Eintrag aus der einen oder anderen Tabelle referenzieren.

Vielleicht ist der Ansatz auch schon total fürn A**** ... hoffe auf eure Mithilfe.

[Forumsgast]

Hi.

Ich vermute mal, es wird geschickt sein, die beiden Tabellen zu einer zusammenzuführen und eben nur dem Skript, das die Updates zieht die Reche geben, die "statischen" Datensätze zu verändern/löschen. Vererbung wäre hier natürlich toll. *g

Basti

[Forumsgast]

hmm..

die Lösung fällt weg, da ich von meinem Chef die Anweisung bekommen habe, dass diese Tabelle nicht editiert werden soll... Wegen offiziellen Updates dieser Tabelle, die wir immer geliefert bekommen.

Noch jemand eine Idee?

[Forumsgast]

Musst sie ja nicht editieren. Kannst sie ja auch zwecks Chef-Beruhigung parallel und dort unverändert speichern. Dazu importierst du die Daten in deine normale Tabelle. Kannst diese ja noch mit einem Flag extra als "statische" Datensätze markieren und beim nächsten Update der Daten löschst du einfach alle "statischen" Datensätze und ziehst deine neue Original-Tabelle wieder drüber.

Aber auch ohne die unveränderte Tabelle bleiben die Daten, wenn du sie nicht editierst doch uneditiert, oder nicht? Und wenn die Anwendung keinen Schreibzugriff auf die Datensätze hat, sondern nur das Update-Skrip, dann kannst du noch so viel Mist programmieren (außer, beim Update die Rechte falsch setzen!) - die Daten bleiben unverändert.

Frag deinen Chef doch mal, ob er will, dass die Daten unverändert bleiben, oder ob er dir Steine in den Weg legen will, weil er dir nicht vertraut, das du das hinbekommst.

Andernfalls musst du halt schauen, wie du die IDs zusammenbekommst. An einfachsten wäre hier, wenn beide aus unterschiedlichen Wertemengen wären, wenn also die IDs deiner "dynamischen" Daten z.B. mit einem Unterstrich anfangen, was bei den anderen IDs z.B. nicht erlaubt wäre. Wenn die "statischen" IDs immer genau 11 Zeichen lang sind, ist das ja eh kein Problem. Musst halt sicherstellen, dass zukünftig hinzugefügte Datensätze der "statischen" Datenbank deine "dynamischen" Datensätze nicht "überschreiben" werden.

Jo, und mit den Abfragen musst du dann halt in den Sauren Apfel beißen und immer beide Tabellen ansprechen.

Aber nur, damit der Chef seine Idee im Kasten hat, würd ich mir das nicht unbedingt antun. Aber ich hab auch leicht reden - bin ja mein eigener Chef.

Ist ja letztlich auch nicht so wichtig. Hauptsache, die IDs gehen sich "zukunftssicher" aus dem Weg. Wenn das nicht möglich ist, dann musst du halt jeweils dazuspeichern, was die Datenquelle ist und hast halt entsprechend mehr Abfragen.

Basti

[Forumsgast]

Dann nimm doch diese VARCHAR(11) auch als Primärschlüssel für deine dynamischen Daten, oder warum solltest du jetzt plötzlich einen neuen Primärschlüssel INT(9) verwenden?

Notfalls halt

static_table
id VARCHAR(9) | column1 | ..

dynamic_table
id INT(9) | static_id VARCHAR(9) | column1 | ..

[Forumsgast]

wegen evtl. auftretender Doppelbezeichnungen in der anderen Tabelle