Liebe Mitglieder,
in diesem Fall fehlt mir aufgrund der wenigen Erfahrung auf diesem Gebiet ein sinnvoller Ansatz, ein Best-Practice-Beispiel oder ggf. auch nur ein Schlagwort um mich weiter einzulesen.
Es geht darum, eine für mich komplexe Datenbankstruktur zu erstellen, die es möglich macht Daten "definierten Zeiträumen" zuzuordnen, gleichzeitig wenig Redundanz aufkommen lässt und die Performance dabei natürlich nicht vergisst.
Am einfachsten ist vermutlich ein kleines Beispiel:
Man stelle sich eine Benutzergruppe mit ca. 2000 Mitgliedern vor, die jeweils für einen fest definierten Zeitraum mehreren Projekten zugeordnet werden sollen. Für jeden Zeitraum kommen ca. 200 Mitglieder dazu, damit man eine Einschätzung über das Datenvolumen bekommt. Klassischerweise hatte ich die Idee, die Mitglieder, die Projekte und auch die "fest definierten" Zeiträume in einer Datenbanktabelle zu erfassen. Mein Problem ist nun, dass die Relation Zeitraum, Projekt, Mitglied nur eine von vielen in dieser Art ist und es neben diesen Verknüpfungen auch noch weitere Beziehungen gibt. Man denke an Projektleiter, Ressourcen wie Räume, ... die natürlich jeweils mit den Projekten bzw. Mitgliedern in Abhängigkeit des Zeitraums verknüpfbar sein müssen.
So dachte ich an eine Tabelle (nennen wir sie "period"), die die Zeiträume beschreibt (ich vereinfache ein wenig)
Natürlich an Mitglieder
und an die Projekte
Und an die n:m Verknüpfung der Projekte und der Mitglieder
An irgendeiner Stelle muss ja nun die Relation zum Zeitraum untergebracht werden. Wird diese in der Verknüpfungstabelle aufgenommen oder wird das Projekt einem Zeitraum zugeordnet oder beides? Ich würde diese nur an die Projektetabelle angliedern.
Wie sieht das in der Praxis mit der Performance aus? Ich erhalte mit den Testdaten und ersten Versuchen aufgrund der angedeuteten weiteren Beziehungen, die sich auch am jeweiligen Zeitraum orientieren, unglaublich lange Ladezeiten, da sich in den SQL Abfragen durchaus bis zu 6 Joins finden und erhalte damit Ladezeiten jenseits von 1 Sekunde, was wohl nicht im Sinne des Erfinders sein kann.
Liegt das Problem grundsätzlich im Datenbankdesign?
Ich hatte zwischenzeitlich auch schon die glorreiche Idee, für jeden neuen Zeitraum neue Tabellen zu generieren, die sozusagen "Rückschlüsse" auf den Zeitraum zulassen, so dass mit einer Konstante (oder wie auch immer umgesetzt) jeweils nur die aktuell ausgewählten Tabellen abgefragt werden, was zwar die Performance erhöht hat, aber ich damit natürlich nur noch schwer Beziehungen zwischen den Zeiträumen abbilden kann, was derzeit zwar nicht notwendig wäre, aber eine solche Umsetzung behagte mir nicht wirklich.
Dennoch hoffe ich, dass ich mein Problem anschaulich darstellen konnte. Ich freue mich über jede Rückfrage oder Ideen, die mir weiterhilft mein Problem überhaupt strukturell zu erfassen. Für diese Art des Designs bzw. die Idee, die ich damit verfolge wird es doch bestimmt einen Namen geben. Bin bin gespannt.
Viele Grüße
Guido
in diesem Fall fehlt mir aufgrund der wenigen Erfahrung auf diesem Gebiet ein sinnvoller Ansatz, ein Best-Practice-Beispiel oder ggf. auch nur ein Schlagwort um mich weiter einzulesen.
Es geht darum, eine für mich komplexe Datenbankstruktur zu erstellen, die es möglich macht Daten "definierten Zeiträumen" zuzuordnen, gleichzeitig wenig Redundanz aufkommen lässt und die Performance dabei natürlich nicht vergisst.
Am einfachsten ist vermutlich ein kleines Beispiel:
Man stelle sich eine Benutzergruppe mit ca. 2000 Mitgliedern vor, die jeweils für einen fest definierten Zeitraum mehreren Projekten zugeordnet werden sollen. Für jeden Zeitraum kommen ca. 200 Mitglieder dazu, damit man eine Einschätzung über das Datenvolumen bekommt. Klassischerweise hatte ich die Idee, die Mitglieder, die Projekte und auch die "fest definierten" Zeiträume in einer Datenbanktabelle zu erfassen. Mein Problem ist nun, dass die Relation Zeitraum, Projekt, Mitglied nur eine von vielen in dieser Art ist und es neben diesen Verknüpfungen auch noch weitere Beziehungen gibt. Man denke an Projektleiter, Ressourcen wie Räume, ... die natürlich jeweils mit den Projekten bzw. Mitgliedern in Abhängigkeit des Zeitraums verknüpfbar sein müssen.
So dachte ich an eine Tabelle (nennen wir sie "period"), die die Zeiträume beschreibt (ich vereinfache ein wenig)
Code:
id|name 1|Zeitraum 1
Code:
id|name 1|Björn Beispiel
Code:
id|name|period_id 1|Projekt A|1 2|Projekt B|1
Code:
user_id|project_id|period_id 1|1|1 1|2|1
Wie sieht das in der Praxis mit der Performance aus? Ich erhalte mit den Testdaten und ersten Versuchen aufgrund der angedeuteten weiteren Beziehungen, die sich auch am jeweiligen Zeitraum orientieren, unglaublich lange Ladezeiten, da sich in den SQL Abfragen durchaus bis zu 6 Joins finden und erhalte damit Ladezeiten jenseits von 1 Sekunde, was wohl nicht im Sinne des Erfinders sein kann.
Liegt das Problem grundsätzlich im Datenbankdesign?
Ich hatte zwischenzeitlich auch schon die glorreiche Idee, für jeden neuen Zeitraum neue Tabellen zu generieren, die sozusagen "Rückschlüsse" auf den Zeitraum zulassen, so dass mit einer Konstante (oder wie auch immer umgesetzt) jeweils nur die aktuell ausgewählten Tabellen abgefragt werden, was zwar die Performance erhöht hat, aber ich damit natürlich nur noch schwer Beziehungen zwischen den Zeiträumen abbilden kann, was derzeit zwar nicht notwendig wäre, aber eine solche Umsetzung behagte mir nicht wirklich.
Dennoch hoffe ich, dass ich mein Problem anschaulich darstellen konnte. Ich freue mich über jede Rückfrage oder Ideen, die mir weiterhilft mein Problem überhaupt strukturell zu erfassen. Für diese Art des Designs bzw. die Idee, die ich damit verfolge wird es doch bestimmt einen Namen geben. Bin bin gespannt.
Viele Grüße
Guido
Kommentar