4. Dynamische Datenbankstrukturen verschiedener Module

Dynamische Datenbankstrukturen verschiedener Module

  • ?

    Hi,

    folgende Problematik steht zur Diskussion 😕

    In einer Webanwendung gibt es ein Modul (Stammdaten), mit dem der Benutzer Daten in der DB speichern kann. (Textfelder, Datumsfelder, Auswahlboxen). Die Felder sind konfigurierbar, so dass neue Eingabefelder jederzeit hinzugefügt werden.

    Entsprechend der Datentypen gibt es in der Datenbank Tabellen für Integer-Werte, Datums-Werte, Text-Wert usw.

    Nun zur eigentlichen Frage:
    Hat man nun in einer Webanwendung mehrere logisch getrennte Module (verschiedene Eingabemasken) mit einer solchen Struktur, sollte man dann alle Daten in den gleichen Tabellen speichern oder lieber jeweils eine identische Struktur pro Modul aufbauen?

    0
  • N

    Klingt so als könntest du das recht simpel mit ein paar 1:n Beziehungen modellieren.

    Jedes Objekt hat 0 bis n Textfelder, 0 bis n Datumsfelder, 0 bis n Integerwerte, …

    Du hast eine Tabelle für Objekte, eine für Textfelder, eine für Datumsfelder, …

    0

  • Ich denke es wäre besser pro Feld eine eigene Tabelle anzulegen, nicht pro Datentyp.
    Kann man ja auch dynamisch machen, einfach wenn das Feld angelegt wird das entsprechende DDL Statement raustreten das die Tabelle anlegt.

    Der Vorteil dabei ist dass die Tabellen nicht so riesig werden.

    So lange alles über Range-Queries in Indexen optimiert werden kann ist es mehr oder weniger egal, aber sobald das nimmer funktioniert wird ganz schnell wichtig wie gross eine Tabelle ist.

    EDIT: Ein weiterer Vorteil ist dass du dann Referential Integrity Constraints setzen kannst. Wenn du ein Feld "Lieferant-Nummer" hast, dann sollte man da nur gültige Lieferant-Nummern eintragen können. Wenn du den Wert aber in einer gemeinsam genutzten "Integer-Wert" Tabelle speicherst, dann kannst du diesen Constraint nicht in der DB verankern. Muss man nicht immer machen, und es gibt sogar Fälle wo man es gar nicht machen will. Aber oft ist es sehr praktisch. /EDIT

    Potentielle Nachteile fallen mir auch nicht viele ein. Höchstens dass man dann nicht mehr so einfach Abfragen machen kann die z.B. in allen Textfeldern eines Datensatzes suchen. Wobei fraglich ist ob man solche Abfragen braucht. Und notfalls kann man sie ja auch machen, nur muss dort dann halt dynamic SQL verwenden.

    0

  • Und falls du wirklich bei einer Tabelle pro Datentyp bleiben willst...

    DynamicDB schrieb:

    Nun zur eigentlichen Frage:
    Hat man nun in einer Webanwendung mehrere logisch getrennte Module (verschiedene Eingabemasken) mit einer solchen Struktur, sollte man dann alle Daten in den gleichen Tabellen speichern oder lieber jeweils eine identische Struktur pro Modul aufbauen?

    Ich würde sagen getrennte Tabellen für die einzelnen Module. Aus dem selben Grund warum ich eine Tabelle pro Feld vorgeschlagen habe, also damit die Tabellen nicht so gross werden.

    Wobei "Modul" mMn. eine ungünstige Bezeichnung ist. Es geht nicht um Module sondern um "Entity-Typen". "Lagerverwaltung" könnte z.B. ein Modul sein, aber "Regal" und "Halle" sind verschiedene "Entity-Typen".

    0
  • N

    hustbaer schrieb:

    Ich denke es wäre besser pro Feld eine eigene Tabelle anzulegen, nicht pro Datentyp.

    Das kommt stark darauf an, was man damit machen möchte.

    Bei den von dir genannten Beispielen: Klar. Bei einer simplen Umfrageverwaltung oä. ist mein Vorschlag viel simpler (weniger bewegliche Teile). An sowas hatte ich auch gedacht, weil ich Anfang des Jahres jemanden auf so ein Projekt angesetzt habe, wo der Entwickler auch Schwierigkeiten hatte, sich alleine eine sinnvolle DB-Struktur auszudenken.

    0
Anmelden zum Antworten