Typensichere Parametertabelle

[basti01985]

Es geht allgemein darum zb. für zwei verschiedene Subjekte Parameter abzulegen.
Wichtig wäre es hier der Ansatz einer Datenbankstruktur, in der die Parameter sowohl typisiert als auch hinsichtlich der Anzahl flexibel ablegt sind.


Dabei ist folgender Ansatz nicht erwünscht:

Tabelle1 (Subjekt1):

IDSubjekt1 Prop1 Prop2 Prop3 Prop4


Tabelle2 (Subjekt2):

IDSubjekt2 Prop1 Prop2 Prop3 Prop4


Dieser Ansatz ist zwar im weitesten Sinne "normalisiert", allerdings bietet er nicht die gewünschte Flexibilität.

Gerade hinsichtlich beliebig vieler möglicher Parameter wäre hier eine folgende Strukturierung hilfreicher:

Tabelle1 (Subjekt1):

IDSubjekt1 IDProp PropValue

dies lässt sich noch wie folgt erweitern um die Daten der zweite Tabelle mit abzulegen.

Tabelle (Parameter von Subjekt1+2):

IDSubjekt IDProp PropValue


Nun wäre man hinsichtlich der Anzahl der Subjekte und Anzahl der Parameter hinsichtlich der Anzahl flexibel.

Allerdings ist nunmehr der Datentyp der "PropValue" Spalte auf eben einen einzigen Datentypen reduziert.

Hat hier jemand Ideen, Erfahrungswerte, Vorschläge?
Danke für die Hilfe.

[fanderlf]

Muss das in der DB passieren? Dann wird Dir nur die Variante mit den mehreren Spalten bleiben. Hier musst Du dann abfragen welche Spalte null ist. Alternativ kann man auch mehrere Tabellen machen (pro Variablentype eine - allerdings braucht man dann sehr viel JOINs).

Ich würde das ganze "clientseitig" machen. Also in Deinem Programm was die DB verwendet, sofern das möglich ist. An dieser Stelle halte ich es nicht für sinnvoll zu viel Arbeit in die DB zu stecken. Letzten endes ist diese doch bloß ein Datenspeicher. Vorsicht sollte man nur bei Gleitkommawerten walten lassen, denn hier ist die Konvertierung meist etwas gefährlich. Wenn man die Konvertierei allerdings auf clientseite schon vor nimmt, dann sollte das eigentlich auch kein großes Problem darstellen. Du hast ja volle Kontrolle drüber was wie konvertiert wird. Bei dieser Version brauchst Du noch eine Spalte die angibt um welchen Typ von Property es sich handelt. Viele OR Mapper bilden so auch die Vererbung ab.

Meine Meinung: Zu viel Normalisierung ist an dieser Stelle nicht angebracht.

[basti01985]

"Clientseitig" dürfte hier ein Problem darstellen, da die Daten innerhalb einer Netzdatenbank mehreren Clients zur Verfügung gestellt werden müssen.

Die 1. Idee mit den "Je Datentyp eine Spalte" hatte ich auch bereits im Hinterkopf in Verbindung mit einer "Datentyp-Spalte" in der angegeben wird, unter welchem Datentyp der Wert zu finden ist. Aber dies ist alles andere als elegant wie mir scheint und kann spätestens bei komplexeren Abfragen zu sehr viel Overhead führen...

Die 2. Idee, das Speichern unter einem bestimmten Datentypen (nvarchar) ist aber mindestens genauso "un-elegant" da eine spätere Konvertierung auf Objektebene sehr problematisch scheint.

Die 3. Idee wäre die von dir angesprochen Aufteilung in unterschiedliche Tabellen, aber dies wäre aufgrund der erhöhten Komplexität in Form der Joins fast mit der 1. Idee vergleichbar..

Bin momentan leider noch etwas ratlos, was hier der sinnigste Ansatz ist. Oder aber ob man noch andere Möglichkeiten übersehen hat.

[dimitri]

Also wenn ihr überhaupt nicht wisst, welche daten dort abgelegt sind, dann wird die Art der Daten gespeichert und die daten selbst liegen in einer BLOB Spalte. Die Anwendung muss dann eben anhand der Metasinformationen die korrekte Konvertierung vornehmen.
Das macht es nicht einfacher, aber wer sagt denn, dass unbegrenzte Flexibilität einfach sein muss

Dim

[Christian Marquardt]

Es gibt doch hier nur 2 Wege:

- entweder je Parameter eine Spalte oder
- die Werte im Programm casten (umwandeln)

Mit erscheint letzteres die sinnvollste Lösung. Im Programm gibt es einen Zugriffspunkt für das lesen der Daten und nur dort muss die Umwandlung gemacht werden

[tinof]

Also ich habe vor ca. 1 Jahr so eine ähnliche Tabelle für Parametereinstellungen angelegt, mit 2 typbezogenen Spalten:

pString Varchar(100),
pInt Integer

und dem Plan, die Daten hier typsicher abzulegen.

Eine aktualle Analyse zeigt, dass eigentlich nur noch die pString - Spalte Verwendung findet.

Ganz anders wäre ein XML - Typ (wenn vom RDBMS unterstützt) ein sehr sauberer Ansatz.