Tabellen zur Laufzeit erstellen



  • Hallo!

    Was haltet ihr eigentlich davon in einer Datenbank Tabellen zur Laufzeit zu erstellen, die dann auch nicht mehr gelöscht werden?

    Ich persönlich, der ja noch nicht so viel Ahnung von Datenbanken hat, würde sagen, dass dies doch eigentlich nie nötig ist, sondern nur auf schlechtes Datenbankdesign beruht. Was sagt ihr dazu?

    Ich bin nämlich gerade in einem kleinen Studentenprojekt involviert, in der in einer Datenbank Tabellen zur Laufzeit erstellt werden. Man weiss also gar nicht, wie viele Tabellen die Datenbank irgendwann einmal enthält. Das geht doch bestimmt irgendwann auch auf Lasten der Datenbankperfomance, oder?

    Die Datenbank ist mySQL, und die Tabellen die Zur Laufzeit erstellt werden können enthalten dann ca. 5-70 Spalten (je nachdem, wie viel Sensoren an unser Messgerät angeschlossen sind). Es geht darum Referenzparameter von einem Messaufbau abzuspeichern, wo man vorher nicht weiss, wie viele Sensoren angeschlossen sind.

    Aber um so etwas zu realisieren gibt es doch sicher auch andere Möglichkeiten, als Tabellen dynamisch zu erstellen, oder?

    Ich würde z.B. jeden Referenzensatzt mit einigen zusätzlichen Parametern in einer Binärdatei abspeichern, und diese Binärdatei dann in eine Tabelle als Blob abspeichern. So hätte ich eine Tabelle für Referenzen, und gut ist. Was sagt ihr dazu, oder gibt es noch andere (bessere) Wege?

    Gruß
    Maik



  • Es gibt sicher Fälle wo das nötig ist. Grundsätzlich sollte man es aber nicht machen.
    Hier ist eine Normalisierung besser.
    z.B. Ein Eintrag pro Sensor.



  • Es gibt sicher Fälle wo das nötig ist

    Kannst du vielleicht mal ein Beispiel nennen?

    Hier ist eine Normalisierung besser.

    Mit Normalisierung meinst du doch so eine Vorgehensweise aus der Entwicklung einer relationalen Datenbank, oder? Wie gesagt, ich bin nicht ganz so fit in Datenbanken. . .



  • ich hab ein ähnliches Projekt: mehrere Geräte schicken Messwerte in eine Datenbank und die Anzahl der Geräte ist nach oben offen

    eine Tabelle "Geraete" mit den Gerätedaten (primary key = Seriennummer)
    eine Tabelle "Messwerte" mit Messwerten mit folgenden Spalten:
    - Index
    - Seriennummer
    - Datum/Zeit
    - Messwert1
    - Messwert2

    die Anzeige der Messwerte für ein einzelnes Gerät geht dann mittels SQL, z.B.
    select * from Messwerte where Seriennummer = '0152367a'

    d.h. dauerhaft nur 2 Tabellen

    Grüße
    Linnea



  • Kiamur schrieb:

    Es gibt sicher Fälle wo das nötig ist

    Kannst du vielleicht mal ein Beispiel nennen?

    Nein, weil ich es noch nie brauchte. Bin immer mit Normalisierung ausgekommen. Infos gibts bei google. Ist nicht so einfach erklärt.
    Es geht aber daraum nicht die gleichen Daten in verschiedenen Tabellen bereit zu halten sondern eine REF. darauf.



  • Vielen Dank für eure Antworten. Das hat mir schon weitergeholfen !!!

    Gruß
    Maik



  • Hi,

    ich arbeite auch zur Zeit an einen Forschungsprojekt. Es handelt sich um Datamining im Manufactoting Process. Zur Zeit optimieren wir die SpecLimits von Parametern um den Gewinn zu steigern. Kommen wir zurück zum Thema. Da wir Daten von 10 verschieden Unternehmen sammeln, benötigten wir auch ein zieml. flexibles Schema.

    Das mit den dynamischen Relationen ist nicht besonders intelligent gelöst. Ich kann mal ein Ansatz geben:

    Product 1-n UnitReport
    Serial 1-n UnitReport
    Station 1-n UnitReport
    UnitReport 1-n TestRun
    Test 1-n TestRun
    Test 1-n Test (ChildTests)

    TestRun 1-n ResultValue
    Propert 1-n ResultValue

    Es ist nur ein kleiner Ausschnitt, leider kann ich dir auch nicht mehr Details geben. Ich hoffe das es trotzdem ein bisschen hilft.



  • Und was soll uns das jetzt sagen. Du musst bei denen Antworten immer vom Wissen des Fragestellers ausgehen. Er hat geschrieben das er noch wenig Ahnung von Datenbanken hat.



  • @grenouille_unreg: Leider muss ich Unix-Tom Recht geben. Mit deiner Antwort kann ich leider nicht viel anfangen, auch wenn sie vielleicht nett gemeint ist.

    Das mit den dynamischen Relationen ist nicht besonders intelligent gelöst.

    Hier frage ich mich nun, ob du damit sagen willst, dass das erstellen von dynamischen Tabellen nicht besonders intelligent ist (also nach meinem Verständnis das Erstellen von Tabellen zur Laufzeit), oder ob ein Realationales Datenbankmodel nicht besonders intelligent ist, wie es Linnea beschrieben hat.

    Vielleicht schreibst du ja noch mal einen Satz dazu.

    Gruß
    Maik


Anmelden zum Antworten