Datenbankdesign: Dynamische Daten speichern

[Linor]

Es ist schon klar das EINE Tabelle mit nur DREI Felder nicht reicht, es sollte ja auch nur zeigen wie man verschiedene Daten in einer Tabelle unterbringen könnte...

Idealerweise gibt es zur Geräte-Tabelle eine Checklisten-Tabelle, könnnem ja mehrere sein, und dann halt die Nutzdaten-Tabelle die dann aus Checklisten-Id, Schlüssel, Typ und Daten besteht.

[Furtbichler]

Ja, stimmt, bei deinem Prinzip fehlte sowieso der Verweis zum Gerät.

[Xzeer]

Schon mal danke für die super Antworten bisher. Hat mir schon geholfen und ich habe jetzt mal versucht eure Ideen in einem Datenbankdiagramm umzusetzten.
Habe ich das so richtig verstanden?

Datenbank.JPG

[Linor]

Nein, eigentlich nicht, denn aus deiner Struktur heraus hat jedes Gerät genau eine Checkliste, und damit sind die anderen fast alle über...

Du brauchst dann nur eine Tabelle mit den Feldern: Gerät, Schlüssel, Typ, Daten

Ob du die Schlüssel in einer Tabelle definierst, kommt drauf was du damit machen willst und woher die Daten kommen. Sinn macht das wenn du eine Suche auslösen willst: Alle Geräte die VOLTAGE = 230 haben... Dann könntest du auch das Feld Typ weglassen und dieses in die Schlüssel-Tabelle verlagern:

Tabelle 1: Gerät, Bezeichnung
Tabelle 2: Schlüssel, Typ
Tabelle 3: Gerät, Schlüssel, Daten

Nur später darauf achten, das einmal angelegte Schlüssel nur schwerlich wieder änderbar sind. Sollten anlegbar und löschbar sein. Änderbar erfordert evtl. ein konvertieren aller Daten in Tabelle 3.

[Daniela.S]

Kann es sein, dass du so etwas in der Richtung brauchst (als ERM Dargestellt)?
Eine extra Tabelle für "Checkliste" ist nicht unbedingt notwendig, da die nur eine 1:1 Beziehung zu Tabelle "Typ" eingehen würde.

Der Wert selbst wäre eine n:m Verbindung, sprich eine eigene Tabelle mit FK von "Gerät" und "Property" an der auch das Attribut "Value" hängt...

[Iwo Asnet]

Zitat von Linor:

Nur später darauf achten, das einmal angelegte Schlüssel nur schwerlich wieder änderbar sind. Sollten anlegbar und löschbar sein. Änderbar erfordert evtl. ein konvertieren aller Daten in Tabelle 3.

Deswegen nimmt man dafür nichtsprechende Schlüssel, wie z.B. Zähler oder GUID. Beides wird von RDBMS unterstützt (Generatoren, AutoInc, Identity, etc.).



@Daniela: Wenn man Gerätetypen hat (also mehrere Geräte eines Typs) aber pro Gerätetyp jeweils genau und nur eine Checkliste, dann müsste man das erweitern. Ich denke auch, eine Checkliste pro Gerät(etyp) reicht erst einmal, oder?

[Daniela.S]

In dem Fall, den ich modelliert habe, hätte man eine Checkliste pro Gerätetyp. Man müsste also nicht jedes mal eine neue Checkliste anlegen wenn ein Gerät des gleichen Typs angelegt wird, denn jeder Typ hat seine vordefinierte Checkliste. Die muss man nur anlegen wenn ein neuer Gerätetyp angelegt wird. Der Wert selber wird über Property und Gerät referenziert.

[bernhard_LA]

für sich laufend verändernde Daten verwende ich folgende Abänderung der Vorschläge von oben


Feld1 : Key
Feld2 : Unique ElementDaten
feld3 : ....
Feld4 : BLOB mit einer XML Datei

Über den Aufbau der XML Datei können beliebige Inhalte Kodieren und ablegen, unser XML BLOB Feld-Zugriff wird mir jedem Erweiterung der Datenstruktur angepasst