Gerade bei älteren Projekte waren zum Zeitpunkt des Entwurfs noch keine
SQL-Datenbanken geplant.
Die Zugriffszeiten waren häufig direkt proportional der Menge der gespeicherten Daten in einer Tabelle.
Deshalb hatte es da durchaus Sinn ältere oder wenig gebrauchte Daten auszulagern.
Bei einem späteren Umstieg wird in der Regel kein Datenbankdesigner beauftragt, kostet ja alles erst einmal Zeit und Geld. Man verändert das Konzept nicht sondern verlagert nur die Daten. Damit spart man auch gleich den Aufwand die Abfragen im Programm zu optimieren. Solange die Software damit alle gestellten Anforderungen erfüllen kann, ist auch alles in Ordnung. Ist das nicht mehr der Fall, hat man natürlich das Problem dem Kunden klar zu machen, daß eine Weiterentwicklung nur mit einer relativ aufwendigen Änderung der Grundstrukur möglich ist.
- Analyse der vorhandenen Anwendungsfälle und Anwendungstest entwickeln
- neue Datenstruktur entwickeln
- Ersetzen der alten Tabellen durch
DB-View und/oder
DB-Procedure für alte Programmteile
- Konvertierung der Daten
- Testen
Zitat:
2. Spalte als "Foreign Key" zeigt auf unterschiedliche Tabellen.
Ich habe drei Tabellen: A1, A2 und B. B enhält eine Spalte 'FID' und eine Spalte 'FTBL'.
In FID steht eine ID drin. Wenn in FTBL der Wert 'A1' steht, dann ist die ID der PK von A1. Steht in FTBL 'A2', ist die ID der PK von A2.
Das hört sich eigentlich so an als währen A1 und A2 Rollen von B.
Dann ist die ID in A1, A2 und B Primärschlüssel, in A1 und A2 zusätzlich "Foreign Key" auf B.
B <- A1
B <- A2
Als Objektmodel:
- Das Objekt wird immer mit ID und den Eigenschaften der Basisklasse in B gespeichert.
- Für Ableitungen(A1) werden unter der selben ID in der Tabelle A1 die zusätzlichen Eigenschaften gespeichert
- Für Ableitungen(A2) werden unter der selben ID in der Tabelle A2 die zusätzlichen Eigenschaften gespeichert