Wir haben ein Datenmodell das sich sehr stark an einen Objektorientierten Ansatz anlehnt. So haben wir beispielsweise Tabellen für Geräte, Personen, Räume... die von einer Ressourcentabelle "erben" (Table per Type [TPT]), der wiederum allgemeine Informationen zugeordnet (z.B. Schlagwörter/Tags, Zusatzdaten, Dokumente...) werden. Mit der Zeit wurde von Kundenseite für immer mehr Datentypen die Zuordnung dieser allgemeinen Informationen gewünscht, und stark überspitzt geht es in die Richtung das wir eigentlich für nahezu alle Tabellen eine gemeinsame Basistabelle haben, auf dessen Ebene konfigurierbar bestimmte allgemeine Daten zugeordnet werden können (Bei diesen "allgemeinen" Daten handelt es sich ebenso um nicht nur eine Tabelle sondern mehrere).
Die Datenbank ist schon lange an die Grenzen gestoßen, das es zu viele Abhängigkeiten zu einzelnen Tabellen gab, so das wir an vielen Stellen die Beziehungen nicht mehr mittels Constraints absichern (und ich regelmäßig nacharbeiten muss, wenn mal wieder festgestellt wird das man im Code an einer Stelle dies auch übersehen hat, und wieder mal Datenleichen entstanden sind). Die bisherige "Datenbank" *hust* kennt weder Trigger noch STPs, so das man hier auch nichts auf DB-Seite machen konnte... damit soll nun aber Schluß sein, der Wechsel auf ein richtiges Datenbanksystem ist nun in der Planung (bedingt durch die Verbreitung auf Kundenseite wird es MS SQL Server).
Das stellt sich aktuell im wesentlichen wie folgt dar:
Nun stellt sich für mich hier dennoch die Frage was der sinnvollste Ansatz ist, wenn man wie bei uns auf der einen Seite viele Tabellen hat, die teilweise untereinander nichts oder nur wenig gemeinsam haben, auf der anderen Seite aber auch Tabellen mit allgemeinen/informativen Daten die möglichst vielen davon zugeordnet werden können. Für jede Möglichkeit eine eigene Zuordnungstabelle zu erstellen lässt die Tabellenanzahl in extreme Höhen schiessen, ob eine gemeinsame "Basistabelle" für die allgemeinen Zuordnungen der sinnvolle Ansatz ist, bezweifel ich aber eigentlich auch.
Mir persönlich (aber ich bin auch kein gelernter DB-Administrator) stellen sich hierbei mehrere Ansätze:
1. (schließe ich aus) Wirklich jeder Zuordnungsmöglichkeit hierbei eine eigene Verknüpfungstabelle zu spendieren. Dies halte ich weder von der Wartbarkeit noch der Übersicht für sinnvoll.
2. Alle Tabellen die eine Verknüpfung von allgemeinen Daten vorsehen, "erben" (wie bisher) von einer Basistabelle (nennen wir sie einmal TblObjekt), auf deren Ebene die allgemeinen Daten verknüpft werden (Objekt<->Schlagwort, Objekt<->Zusatzdatum...). Die Id dieser Basistabelle dient als Id der "abgeleiteten" Datensätze (z.B. ein Datensatz in der Personentabelle hat als Id die IdObjekt der TblObjekt). Die Beziehung der "Vererbung" wird wegen der hohen Anzahl nicht mit Constraints sondern über Trigger oder STP-Logik gelöst.
3. Alle Tabellen die eine Verknüpfung von allgemeinen Daten vorsehen, erhalten eine gemeinsam genutzte Id-Sequenz, die Verknüpfungstabelle entfällt, alle Abhängigkeiten werden komplett über Trigger oder STP-Logik simuliert.
Vielleicht gibt es aber noch ganz andere Ansätze.
Die Datenbank ist schon lange an die Grenzen gestoßen, das es zu viele Abhängigkeiten zu einzelnen Tabellen gab, so das wir an vielen Stellen die Beziehungen nicht mehr mittels Constraints absichern (und ich regelmäßig nacharbeiten muss, wenn mal wieder festgestellt wird das man im Code an einer Stelle dies auch übersehen hat, und wieder mal Datenleichen entstanden sind). Die bisherige "Datenbank" *hust* kennt weder Trigger noch STPs, so das man hier auch nichts auf DB-Seite machen konnte... damit soll nun aber Schluß sein, der Wechsel auf ein richtiges Datenbanksystem ist nun in der Planung (bedingt durch die Verbreitung auf Kundenseite wird es MS SQL Server).
Das stellt sich aktuell im wesentlichen wie folgt dar:
Code:
TblObjekt <--> TblSchlagwort (und weitere allgemeingültige Tabellen)
| |
TblGeraet TblRaum (und noch viele andere Tabellen die von TblObjekt "erben").Nun stellt sich für mich hier dennoch die Frage was der sinnvollste Ansatz ist, wenn man wie bei uns auf der einen Seite viele Tabellen hat, die teilweise untereinander nichts oder nur wenig gemeinsam haben, auf der anderen Seite aber auch Tabellen mit allgemeinen/informativen Daten die möglichst vielen davon zugeordnet werden können. Für jede Möglichkeit eine eigene Zuordnungstabelle zu erstellen lässt die Tabellenanzahl in extreme Höhen schiessen, ob eine gemeinsame "Basistabelle" für die allgemeinen Zuordnungen der sinnvolle Ansatz ist, bezweifel ich aber eigentlich auch.
Mir persönlich (aber ich bin auch kein gelernter DB-Administrator) stellen sich hierbei mehrere Ansätze:
1. (schließe ich aus) Wirklich jeder Zuordnungsmöglichkeit hierbei eine eigene Verknüpfungstabelle zu spendieren. Dies halte ich weder von der Wartbarkeit noch der Übersicht für sinnvoll.
2. Alle Tabellen die eine Verknüpfung von allgemeinen Daten vorsehen, "erben" (wie bisher) von einer Basistabelle (nennen wir sie einmal TblObjekt), auf deren Ebene die allgemeinen Daten verknüpft werden (Objekt<->Schlagwort, Objekt<->Zusatzdatum...). Die Id dieser Basistabelle dient als Id der "abgeleiteten" Datensätze (z.B. ein Datensatz in der Personentabelle hat als Id die IdObjekt der TblObjekt). Die Beziehung der "Vererbung" wird wegen der hohen Anzahl nicht mit Constraints sondern über Trigger oder STP-Logik gelöst.
3. Alle Tabellen die eine Verknüpfung von allgemeinen Daten vorsehen, erhalten eine gemeinsam genutzte Id-Sequenz, die Verknüpfungstabelle entfällt, alle Abhängigkeiten werden komplett über Trigger oder STP-Logik simuliert.
Vielleicht gibt es aber noch ganz andere Ansätze.
