[DB] "Dynamisches" Datenbankmodell

[zerafin]

Huhu zusammen,
ich versuche gerade ein Datenbankmodell zu entwerfen und komme nicht so recht weiter, weil beide Möglichkeiten die mir einfallen nicht wirklich schön sind (denke ich). Vielleicht hat Jemand von euch noch eine bessere Idee.

Folgendes möchte ich abbilden:

- Es gibt mehrere Komponenten (Datenbankserver, Applikationsserver, Batchserver, etc.)
- Die Benutzer können selber Komponenten erstellen und vorhandene verändern
- Es können mehrere Exemplare einer Komponente existieren (z.B. mehrere Datenbankserver)
- Die Oberfläche zum Erstellen, Befüllen und Editieren der Komponenten soll für alle Komponenten die selbe sein (sich also entsprechend der Struktur der jeweiligen Komponente anpassen)

Zu einer Komponente sollen beliebig viele Felder existieren, die jeweils folgende Attribute enthalten:

- Titel (z.B. IP, Port)
- Inhalt (z.B. 192.168.2.1, 8080)
- FormularTyp zum Aufbau des HTML Formulars (z.B. Input, Checkbox)
- SortOrder (Reihenfolge in der die Felder im HTML Formular angezeigt werden)

Meine bisherigen Ideen:

Möglichkeit A

Eine Tabelle für die Struktur der Komponenten:
id (int)
titel (varchar)
formType (varchar)
sortOrder (int)

Eine Tabelle für die Inhalte:
id_strukt (int) FK (struktur.id)
id_komp (int) FK (komponenten.id)
value (mixed) -> (Problem: Das können unterschiedliche Datentypen sein.)

Möglichkeit B

Je zwei Tabellen für eine Komponente (Struktur, Inhalt). Das würde bedeuten ich muss bei einer neuen Komponente das Datenbankmodell verändern und eine neue Tabelle anlegen. -> gefällt mir garnicht

Habt ihr noch andere Ideen? Bin für jede Anregung dankbar..

Gruß, Zera

 

[SpecialsGuy]

Versteh ich dein Vorhaben richtig? Naja ... ich versuche es mal

Erstelle eine dritte Tabelle, die alle Komponenten enthält (Gruppe) und dann platziere alle Struktur- und Inhaltsdaten in den zwei anderen von dir erwähnten Tabellen, mit einem Zusatzfeld um diese einer Komponente eindeutig zuzuordnen.

Dann brauchst du keine weiteren Tabellen mehr erstellen, wenn neue Komponenten hinzukommen, sondern nur einen Datensatz in der dritten Tabelle hinzufügen.

 

[zerafin]

Erstelle eine dritte Tabelle, die alle Komponenten enthält (Gruppe) und dann platziere alle Struktur- und Inhaltsdaten in den zwei anderen von dir erwähnten Tabellen, mit einem Zusatzfeld um diese einer Komponente eindeutig zuzuordnen.

Huhu,
das ist meine Möglichkeit A, wenn ich dich richtig verstehe. (id_komp (int) FK (komponenten.id) ist die Verbindung zur von dir angesprochenen dritten Tabelle).

Dann bleibt aber das Problem, dass die Werte verschiedener Attribute verschiedene Datentypen sind. Der Aufbau der zweiten Tabelle für die Inhalte geht also nicht so, wie ich es oben skiziert habe. Oder?

Gruß, Zera

 

[SpecialsGuy]

Möglichkeit A? Huch ... ich hab da wohl beide zusammen gesehen
Wohl das ganze zu schnell überflogen *schäm* ... und was durcheinandergebracht *g*

Leider hat MySQL keinen "Variant"-Typ ... wenn du aber das "simulierst", indem du alle Daten binär abspeicherst und du sie erst im Programm umwandelst? WHERE-Klauseln mit diesen Daten blieben weiterhin nutzbar, wenn du diese insg. bei Vergleichen etc. binär behandelst. Die Umwandlungen könnte ein eigener Layer übernehmen, so würde man im Programm garnichts mehr davon merken. Weiterer Vorteil wäre, du könntest so auch "individuelle" Datenformate definieren, die SQL so womöglich nicht anbieten würde (ich denke jetzt an nichts konkretes, mind. 95% dürfte eh abgedeckt sein).

Alternativ, du machst für jeden möglichen Datentyp ein eigenes Feld ... aber das würde mir selbst nicht sehr gefallen. Der Aufwand hierfür dürfte wohl auch etwas grösser sein.

Wenn du größere Daten abspeichern willst (z.B. längere Texte) würde ich sie dann in eine andere Tabelle unterbringen, so daß das Tabellenformat für die eigentlichen ("kurzen") Daten möglichst effizient bliebe.

 

[zerafin]

Leider hat MySQL keinen "Variant"-Typ ... wenn du aber das "simulierst", indem du alle Daten binär abspeicherst und du sie erst im Programm umwandelst? WHERE-Klauseln mit diesen Daten blieben weiterhin nutzbar, wenn du diese insg. bei Vergleichen etc. binär behandelst. Die Umwandlungen könnte ein eigener Layer übernehmen, so würde man im Programm garnichts mehr davon merken. Weiterer Vorteil wäre, du könntest so auch "individuelle" Datenformate definieren, die SQL so womöglich nicht anbieten würde (ich denke jetzt an nichts konkretes, mind. 95% dürfte eh abgedeckt sein).

Diese Möglichkeit habe ich noch nicht bedacht. Danke für den Tipp! Da googel ich gleich mal ein wenig nach.

Alternativ, du machst für jeden möglichen Datentyp ein eigenes Feld ... aber das würde mir selbst nicht sehr gefallen. Der Aufwand hierfür dürfte wohl auch etwas grösser sein.

Wenn du größere Daten abspeichern willst (z.B. längere Texte) würde ich sie dann in eine andere Tabelle unterbringen, so daß das Tabellenformat für die eigentlichen ("kurzen") Daten möglichst effizient bliebe.

Das wäre auch meine Idee gewesen, das Problem bei Möglichkeit A zu umgehen. Da ich die Auswahl an Datentypen ja in der Eingabemaske zur Erstellung neuer Komponenten begrenzen kann, wäre das relativ einfach zu realisieren. Die Zusätzliche Tabelle für LongText ist eine gute Idee!

Gruß, Zera