Tweet
Datenbankmodellierung
Hallo,
seit ein paar Tagen überlege ich hin und her, wie ich eine Datenbank modellieren soll und kann mich nicht wirklich entscheiden. Vielleicht könnt Ihr mir ja auf die Sprünge helfen
Ziel:
In einer Datenbank sollen Objekte gespeichert werden, die gewisse Eigenschaften haben (oder nicht haben). Diese Eigenschaften kommen aus einem Eigenschaften-Pool, der für alle Objekte identisch ist. Folglich kann das Objekt O1 z. B. die Eigenschaften E1, E2, E5 und E7 haben, das Objekt O2 bspw. die Eigenschaften E94, E1 und E286.
Ich sehe nun drei Möglichkeiten:
1. Für jede mögliche Eigenschaft ein Feld in der Objekt-Tabelle.
2. Eine eigene Tabelle für die Objekt-Eigenschaften, die nur aus dem Objekt-PK und dem Eigenschaften-PK besteht, beides zusammen als PK.
3. Ein Feld in der Objekt-Tabelle, in dem alle zutreffenden Eigenschaften bzw. deren IDs oder Schlüssel gespeichert werden, z. B. durch Kommata getrennt.
Für Punkt 1 spricht vermutlich, dass Abfragen schneller sind als bei den Möglichkeiten 2 und 3. Dagegen spricht wohl, dass bei neuen Eigenschaften die Datenbank modifiziert werden muss und wohl auch die Skripte (1 bis 2 Eigenschaften / Monat)
Bei der Möglichkeit 2 sind keinerlei Modifikationen an der DB nötig, wenn neue Eigenschaften hinzukommen oder alte wegfallen. Jedoch vermute ich, dass die Joins wesentlich langsamer sein werden, wenn die Datenmenge hoch genug ist (s. u.)
Möglichkeit 3 schließlich ist auch äußerst flexibel, doch auch hier werden insbsondere die SELECT-Abfragen eher zeitfressend.
Datenmenge:
Die Anzahl der Objekte wird im Schnitt irgendwo grob bei 100.000 liegen.
Die Anzahl der möglichen Eigenschaften bewegt sich bei ca. 100.
Jedes Objekt wird vermutlich an die 40 - 50 dieser Eigenschaften haben, manche auch mehr, manche viel weniger.
Datenbanknutzung:
Etwa 95 - 98 % der Datenbankzugriffe (bezogen auf die Objekte) werden aus SELECT-Abfragen bestehen, und zwar solchen, bei denen Objekte gefiltert werden, die bestimmte Eigenschaften haben (und auch weiteren Kriterien entsprechen) einerseits und andererseits solchen, die Kriteriums-abhängige Objekte filtern und deren Eigenschaften ermitteln.
1. Zeige mir alle Objekte, die die Eigenschaften E7, E90 und E234 haben;
2. Zeige mir alle Eigenschaften von Objekt O7;
Und nun?
Wie entscheidet man sich hier? Gibt es hierzu empfehlenswerte Vorgehensweisen, Praxiserfahrungen oder "Design Patterns", die sich (samt Empfehlung) anwenden lassen?
Schon mal vielen Dank
pb
seit ein paar Tagen überlege ich hin und her, wie ich eine Datenbank modellieren soll und kann mich nicht wirklich entscheiden. Vielleicht könnt Ihr mir ja auf die Sprünge helfen
Ziel:
In einer Datenbank sollen Objekte gespeichert werden, die gewisse Eigenschaften haben (oder nicht haben). Diese Eigenschaften kommen aus einem Eigenschaften-Pool, der für alle Objekte identisch ist. Folglich kann das Objekt O1 z. B. die Eigenschaften E1, E2, E5 und E7 haben, das Objekt O2 bspw. die Eigenschaften E94, E1 und E286.
Ich sehe nun drei Möglichkeiten:
1. Für jede mögliche Eigenschaft ein Feld in der Objekt-Tabelle.
2. Eine eigene Tabelle für die Objekt-Eigenschaften, die nur aus dem Objekt-PK und dem Eigenschaften-PK besteht, beides zusammen als PK.
3. Ein Feld in der Objekt-Tabelle, in dem alle zutreffenden Eigenschaften bzw. deren IDs oder Schlüssel gespeichert werden, z. B. durch Kommata getrennt.
Für Punkt 1 spricht vermutlich, dass Abfragen schneller sind als bei den Möglichkeiten 2 und 3. Dagegen spricht wohl, dass bei neuen Eigenschaften die Datenbank modifiziert werden muss und wohl auch die Skripte (1 bis 2 Eigenschaften / Monat)
Bei der Möglichkeit 2 sind keinerlei Modifikationen an der DB nötig, wenn neue Eigenschaften hinzukommen oder alte wegfallen. Jedoch vermute ich, dass die Joins wesentlich langsamer sein werden, wenn die Datenmenge hoch genug ist (s. u.)
Möglichkeit 3 schließlich ist auch äußerst flexibel, doch auch hier werden insbsondere die SELECT-Abfragen eher zeitfressend.
Datenmenge:
Die Anzahl der Objekte wird im Schnitt irgendwo grob bei 100.000 liegen.
Die Anzahl der möglichen Eigenschaften bewegt sich bei ca. 100.
Jedes Objekt wird vermutlich an die 40 - 50 dieser Eigenschaften haben, manche auch mehr, manche viel weniger.
Datenbanknutzung:
Etwa 95 - 98 % der Datenbankzugriffe (bezogen auf die Objekte) werden aus SELECT-Abfragen bestehen, und zwar solchen, bei denen Objekte gefiltert werden, die bestimmte Eigenschaften haben (und auch weiteren Kriterien entsprechen) einerseits und andererseits solchen, die Kriteriums-abhängige Objekte filtern und deren Eigenschaften ermitteln.
1. Zeige mir alle Objekte, die die Eigenschaften E7, E90 und E234 haben;
2. Zeige mir alle Eigenschaften von Objekt O7;
Und nun?
Wie entscheidet man sich hier? Gibt es hierzu empfehlenswerte Vorgehensweisen, Praxiserfahrungen oder "Design Patterns", die sich (samt Empfehlung) anwenden lassen?
Schon mal vielen Dank
pb
Kommentar