Datenbankschema für mehrere Benutzer wiederverwenden

Hallo zusammen,

ich bin gerade am Entwickeln einer Datenbankanwendung und stelle mir gerade die Frage, ob es möglich ist ein Datenbankschema für mehrere Benutzer wiederzuverwenden. Dabei können die Relationen der Datenbank für jeden Benutzer andere Daten haben.
Allerdings soll in jeder dieser Relationen ein Fremdschlüssel zu einer Relation existieren, welche von allen Relationen zusammen benutzt werden soll, um Redundanzen zu vermeiden.

Zur besseren Darstellung habe ich noch ein Bild angehängt.

Ich verwende eine mysql-Datenbank.

Viele Grüße
master05

Habe ich das richtig verstanden? Anwender A legt Object1 an. Im Hintergrund sucht die DB im CoreSchema nach einem Objekt, das Object1 entspricht (weil von einem anderen Anwender schon erfasst). Und dann wird dessen CoreID bei Object1 gespeichert.
Korrekt?

Dann hast Du doch aber eine massive Redundanz, weil die eben im COre wie auch in den NutzerDBs abgelegt werden. Mal von den Fragen der Aktualisierung bis hin zum Löschen mal ganz abgesehen…

Hi!

Und warum nicht den Benutzer als eigene Entität anlegen und eine n:m-Verknüpfung auf core_rel?

Oder willst du es Mandantenfähg machen?

Grüße,
Tomh

Schon einmal vielen Dank für Eure Antworten. Vlt sollte ich noch ein Anwendungsszenario geben.

Angenommen es gibt zwei Benutzer (A und B). Für jeden dieser Benutzer gibt es Benutzerspezifische Daten, was im Bild durch die object[1-3] Relation dargestellt werden soll. Diese Benutzerdaten sollen allerdings später mehrere Relationen umfassen, statt nur der einen wie im Beispiel.
Benutzer A speichert nun etwas in seiner object Relation und kann dafür auf Daten in der core_rel verweisen. Gegebenenfalls kann Benutzer A auch Daten zur core_rel hinzufügen. Diese Änderungen sind dann auch für Benutzer B sichtbar.
Benutzer B kann ebenso Daten in seine object Relation hinzufügen, ohne dass A dies mitbekommt.

@Tomh ich denke, dass dies Mandatenfähigkeit sein könnte.

Meine erste naive Umsetzung ist es, dass ich für jeden Benutzer eine eigene Datenbank anlege. Diese Datenbanken haben alle die gleiche Struktur. Die core_rel liegt in einer separaten Datenbank und wird jeweils über Fremdschlüssel aus den Relationen der Benutzer referenziert. Jeder Benutzer hat das Recht Daten in seiner eigenen Datenbank, sowie in der core_rel Datenbank zu verändern.

Eine Alternative die ich noch überlegt hatte wäre wie @Tomh erwähnt hat, eine Relation für die Benutzer anzulegen und in object als Fremdschlüssel hinzuzufügen.

Wäre meine derzeitige Umsetzung denn Mandantenfähig? Bzw. sieht jmd Nachteile daran?

Gruß
master05

Ich verstehe das Problem nicht. Mehrere Datenbanken? Je Benutzer eine? Oder je Benutzer eigene Tabellen? Das widerspricht so ziemlich jedem Ansatz relationaler und damit strukturierter Datenbanken. Was Mandantenfähigkeit mit „eine Datenbank je Benutzer“ zu tun haben soll, ist mir überhaupt nicht eingängig.

Mach es doch einfach mal konkret… Was sind denn das für Objekte? Am Beispiel.

Da du in deinem Fließtext von Benutzern sprichst, aber in deinem Bildchen nicht, versuche ich mir mal was zusammenzureimen:

Was spricht gegen eine Tabelle users

+--------+----------+-----+
| userID | userName | ... |
+--------+----------+-----+
|      1 | Schmidt  |     |
|      2 | Müller   |     |
+--------+----------+-----+

und dann gegen eine Tabelle objects

+----------+--------+--------------+-----+
| objectID | userID | objectNumber | ... |
+----------+--------+--------------+-----+
|        1 |      1 |            1 |     |
|        2 |      1 |            2 |     |
|        3 |      2 |            1 |     |
+----------+--------+--------------+-----+

objectNumer würde sozusagen die Tabellen „object1“ und „object2“ aus deinem Bildchen beziffern. objects.userID wäre der Fremdschlüssel zur users-Tabelle.

P.S: Bitte tu uns den Gefallen und male deine Tabellen nicht auf Papier. Nimm das hier
https://ozh.github.io/ascii-tables/
und füge das Ergebnis hier als vorformatierten Text ein.

Oder - noch besser - entwirf deine Tables im mysql Workbench und kopier hier einen Screenshot rein. Vorteil davon ist, dass du den graphischen Entwurf auf Knopfdruck mit deiner Datenbank synchronisieren kannst. Der legt sozusagen deine Datenbank mit allen Tabellen und Einstellungen für dich an und hält das auch aktuell, wenn du das mal änderst.

Danke für deine Antwort. Im Prinzip spricht erst mal nichts dagegen. Ich denke ich werde das auch wirklich so umsetzen.
Das mit den mehreren Datenbank scheint wirklich keine gute Umsetzung zu sein.

Gruß
master05

Auch mit verschiedenen Tabellen je Benutzer nicht. Die Datenbankstruktur darf niemals (!) von den Benutzerinhalten beeinflusst werden - im Gegenteil. Also neue Daten dürfen niemals zu neuen Spalten oder neuen Tabellen führen. Wenn du das vorhast, verstößt du gegen die Prinzipien relationaler Datenbanken.

Merke: eine Tabelle soll im produktiven Betrieb immer nur nach unten wachsen, niemals in die Breite.

Also… analysiere, welche Daten in deiner Software anfallen können und erzeuge dir dafür die notwendigen Tabellen mit den notwendigen Spalten.

Und dann darfst du nicht vergessen, dass du die Indizes hinsichtlich deiner Abfragen optimieren musst. Wie willst du das machen, wenn sich Struktur und Abfragen immer ändern? Sonst kannst du zusehen, wie die Performance einbricht.

Brich alles soweit runter, bis sich alle in der Software möglichen Objekte in deinen Tabellenstrukturen abbilden lassen. Da du nicht konkret wirst, kann ich dir da nicht konkret helfen.