Allgemeine Modellierung einer Datenbank

[jonas.r]

Hallo ihr =)
Ich bin gerade dabei mir Java beizubringen und nenne mich Fortgeschrittener. Für ein Programm möchte ich nun, dass Daten nicht lokal auf dem PC gespeichert werden, sondern auf einer MySQL-Datenbank, die dann z.B. auch mit einer App angesteuert werden kann.
Leider habe ich sehr wenig Ahnung, wie man eine Datenbank allgemein aufbaut und ich würde mich sehr über Tipps freuen=)

Also erstmal sollen die App mehrere verschiedene User nutzen können. Es sollen also Benutzerkonten erstellt werden. Eine Tabelle dazu wäre dann
id | benutzername | passwort

Nun soll jeder Benutzer auf seinen eigenen Datenbestand zugreifen können. In dem Programm kann jeder User mehrere "Themen", "Gruppen" und "Objekte" anlegen, welche auch langfristig gespeichert werden sollen.

Meine Frage ist nun, ob man einfach nur 3 Tabellen macht also "Thema", "Gruppe" bzw. "Objekt" und wenn man dann die Daten einspeichert ein Thema einfach der userID zuordned, also von jedem User die Daten eines Typs in EINER tabelle gespeichert werden, oder erstellt man für jeden User 3 neue, eigene Tabellen?

Wenn man nur 3 Tabellen hat, müsste man ja jedesmal die jeweilige Tabelle filtern um die Daten zu bekommen. Hat man nun 1000 User, häufen sich da mal schnell 10.000 Gruppen an, welche erstmal gefiltert werden müssen, das macht ja wirklich wenig Sinn... Oder macht man das tatsächlich so?

Ich habe echt keine Ahnung wie man das schlau macht...

Ich freue mich sehr über eure Hilfe!
Liebe Grüße

*Jonas

 

[akretschmer]

Wenn man nur 3 Tabellen hat, müsste man ja jedesmal die jeweilige Tabelle filtern um die Daten zu bekommen. Hat man nun 1000 User, häufen sich da mal schnell 10.000 Gruppen an, welche erstmal gefiltert werden müssen, das macht ja wirklich wenig Sinn... Oder macht man das tatsächlich so?

Ja. Die Alternative wäre, je User eine eigene Tabelle zu machen. Hätte viele Nachteile, z.B. eine Schemaänderung bei jedem neuen User. Du machst Dir wegen 10K Gruppen einen Kopf? Das sind Dimensionen, wo eine DB noch 'kalt' bleibt. Also, mach Dich schlau zum Thema Normalisierung, Indexe und Performance. Und dazu, warum manche (wie ich) MySQL einfach nur meiden.

Und ja: wenn Deine Anwendung aus den Ruder laufen sollte (also mehr als 10 bis 100 Millionen Rows pro Table): Partitioning wurde bereits erfunden.

Andreas

 

[jonas.r]

Echt? Okay dankesehr, ich werde mich genauer informieren, Normalisierung sagt mir auch noch was aus der 10. Klasse =D

 

[ukulele]

Wenn man die Normailisierung verstanden hat kann man sich das ganze häufig mit einem ERD grafisch aufbereiten. Ich für meinen Teil kann damit sehr viel besser planen.

 

[jonas.r]

Hallo ihr=)
Ich hab mir das jetzt mit dem MySQL-Designer grafisch aufbereitet und wollte euch fragen ob das so machbar ist:

Also ein user hat mehrere Themen , welche mehrere Gruppen, welche mehrere Einkaufsobjekte enthalten.

Hups das "topicID" bei der group Tabelle muss natürlich weg.
Aber sonst?

Liebe grüße

*Jonas

 

[ukulele]

Sieht schonmal nicht schlecht aus, auch wenn ich jetzt nicht ganz abschätzen kann ob das wirklich sinnvoll ist. Kann eine group mehren topics angehören (aktuell gegeben) oder immer nur einem? Gleiches gilt für Objekte. Können topics, groups oder objekte mehreren Benutzern gehören? (im Moment nicht geben)

 

[jonas.r]

Oh em jeder User soll vorerst nur seine eigenen Daten haben.
Jedes Thema soll genau einem User zugeordnet werden, jede Gruppe genau einem Thema und jedes Objekt genau einer Gruppe..

Wie muss ich das denn umstellen, damit das so passt?

 

[ukulele]

Dann hättest du nur eine 1:n Beziehung zwischen (Beispiel) User und Topic. Ein User kann mehrere Topics haben aber ein Topic nur einem User gehören. Das führt dazu das die Zwischentabelle entfällt und in topics eine Spalte UserID existiert die zu jedem Topic den zugehörigen User auffindbar macht. user_topics ist also überflüssig... Nach dem Schema läuft es auch in den anderen Fällen.