Starre Datenbankstruktur oder Tabellen bei Bedarf neu erzeugen?

[JanHH]

Hallo,

innerhalb meines Programms gibt es die Möglichkeit, diverse "Unter-Projekte" anzulegen, von denen jedes einen Haufen Daten erzeugt (die abber bei allen Projekten Strukturgleich sind). Alles soll in eine Datenbank. Die Frage ist: Sollte ich lieber eine Datenbank entwerfen, die eine feste Struktur hat, in der alle Daten aller Unter-Projekte gemeinsam in grossen Tabellen landen (so das man über den Namen des Projektes danach suchen kann), oder sollte man lieber zur Laufzeit für jedes Projekt die dafür benötigten Tabellen erzeugen, so dass jedes Projekt seinen eigenen Tabellensatz hat?

Mir wurde gesagt, das eigentlich das erste die korrekte Methode ist.. kommt mir eigentlich auch plausibel vor. Eine einmal entworfene, danach statische Struktur der Datenbank, und die korrekte Abbildung aller Daten aller Projekte wird halt durch vernünftige Modellierung besorgt. Aber die Tabellen werden gross (nicht wirklich gross, aber halt relativ gross). Also wenn man z.B. pro Projekt 1000 Datensätze hat, und 50 Projekte, wären es in Variante 1 eine Tabelle für alle Datensätze, 50.000 Einträge lang, und bei Variante 2 50 Tabellen mit je 1000 Einträgen.

Was ist denn nun zu bevorzugen?

Gruß+Danke
Jan

 

[didjitalist]

der dynamische ansatz macht den code unnötig kompliziert. bei jedem zugriff muss geprüft werden, ob eine bestimmte tabelle bereits existiert. das sorgt für teure sonder- und fehlerbehandlung. ausserdem muss sichergestellt werden, dass anwender, die projekte anlegen und löschen dürfen, auch strukuturelle änderungen an der datenbank vornehmen dürfen. meiner meinung nach ein unnötiges sicherheitsrisiko.

definier für die entsprechende tabelle einfach einen index, der den eindeutigen bezeichner, bzw. die id, des projekts beinhaltet und entsprechende zugriffe bleiben performant. tabellen mit ein paar tausend einträgen sind nicht weiter dramatisch.

 

[JanHH]

Habe das gerade mal durchgerechnet, mit realistischen-aber-eher-pessimistischen Annahmen. Komme dann auf eine einzelne Tabelle, die 22.500.000 Zeilen hat, aus vier Spalten besteht, und jede Zeile ist ca. 50 Zeichen lang. Macht eine Gesamt-Datenmenge von ca. 1 GB. Ist das immer noch so problemlos? Wie gesagt, ein eher pessimistisches Szenario, aber keins, was nicht doch mal vorkommen könnte. Der Zugriff auf die Daten muss dabei im Bedarfsfall "ruckzuck" gehen.

Zur Berechnung: 50 Projekte, in jedes Projekt sind 1500 Personen involviert, und jede Person erzeugt 300 einzelne Daten/Variablen.

Ein etwas optimistisches Szenario wäre: 20 Projekte, pro Projekt 900 Personen, je Person 200 Variablen. Macht nur noch 3.600.000 Zeilen (=ca 171 MB) Datenvolumen. Aber das ist dann wirklich "alltägliches Geschäft".

Ist es wirklich sinnvoll, das alles in eine Tabelle zu stopfen?

 

[JanHH]

Oder man optimiert, datenbankdesigntechnisch..

Also zur Struktur der einzelnen Daten: Es gibt da

"Projekt 1", "Person 1", "Variable 1"
"Projekt 1", "Person 1", "Variable 2"
...
"Projekt 1", "Person 2", "Variable 1"
....
"Projekt 2", "Person 1", "Variable 1"
und so weiter und so fort.

Projekte und Personen können dabei relativ freie Namen haben.

Man könnte nun die Kombination Projekt/Person zusammenfassen in einer weiteren Tabelle, und daraus einen künstlichen Schlüssel generieren, so dass die Einträge in der ursprünglichen Tabelle zumindest deutlich kürzer werden. Also aus "Projekt 1, Person 1" wird der künstliche Schlüssel "1", aus "Projekt 1, Person 2" der Schlüssel "2", aus "Projekt x, Person y" der künstliche Schlüssel "z". Das dürfte die eigentliche Tabelle zumindest um ca. 1/3 verkleinern.

Allerdings wäre dies eine Speicher-Optimierung, was mir gar nicht so sinnvoll erscheint. An sich sind 1 GB grosse Tabellen ja gar kein Problem, denke ich so, und auch 10 GB grosse noch nicht wirklich. Die Kunst ist eher der schnelle Zugriff darauf, und das ist auch das, was in meiner Applikation das wichtigste ist. Wie geht man das denn am besten an?

 

[JanHH]

Mir fällt allerdings gerade auf, das in meiner ersten Tabelle eh noch der eindeutige Primärschlüssel fehlte. Also fünf Spalten statt vier. Macht es nun auch nicht gerade kleiner.

 

[richardkrieger]

Habe gerade was zu Datenbankaufbau geschrieben:
http://www.java-forum.org/datenbankprogrammierung/81251-datenbanken-tabellen-normalisieren.html