Datenmodell mit Metadaten - Datentyp-Problem

[osiris]

Hallo,
ich möchte ein Datenmodell erstellen, welches für die spätere Anwendung auch Metadaten zur Beschaffenheit der Daten selbst bereit hält. Einen Entwurf habe ich bereits, aber an einer Stelle haperts noch.

Ich erkläre kurz den Entwurf: Die Anwendung soll Produktdatenblätter verwalten. Es gibt die "Wurzel"-Relation 'Eintrag', an der beliebige viele Attribute der Relation 'Eintrag_Datenfelder' hängen können. Jedes Tupel aus 'Eintrag_Datenfelder' enthält einen Verweis auf einen entsprechenden Metadateneintrag der Relation 'Datenfeld', Datenfelder sind über 'Datenblatt' gruppiert. Weiterhin wird jedem 'Datenfeld' ein 'Feldtyp' zugeordnet. Ein Feldtyp beschreibt entweder einen Basis-Datentypen wie Integer, Boolean, String oder ist ein Verweis auf einen Stammdateneintrag. 'Stammdaten' ist eine Relation, die später für feste Auswahllisten genutzt werden soll.

Nun zum eigentlichen Problem: Dadurch, dass ich den Datentyp eines Datenfeldes über die Metadatenrelationen beschreibe, kann ich natürlich in der Relation 'Eintrag_Datenfelder' für das Attribut 'wert' nicht den konkreten Datentyp verwenden, da es ja verschiedene Datentypen gibt. Ich nehme also den Datentyp VARCHAR, da er am flexibelsten ist. Trotzdem verliere ich natürlich so alle Vorzüge der eigentlichen Datentypen im Zusammenspiel mit SQL. Aggregationsfunktion über Integer-Datentypen oder der SORT-Befehl werden nicht wie gewünscht nutzbar sein.

Wüsste jemand eine elegantere Lösung, welche die geschilderten Probleme umgeht?

[hwoess]

Warum sollten Aggregatsfunktionen oder SORT nicht möglich sein? Man kann das Feld dazu per CAST/CONVERT immer in den Originaltyp bringen. Allerdings ist so ein Aufbau gut zu überlegen, da Flexibilität immer Overhead und Komplexibilität mit sich bringt. Und die Laufzeit wird auch nicht besser dadurch. Versuche mal mit ein paar unterschiedlichen Stammdatenblättern, die untereinander verjoint sind, eine Query zu erstellen, die dann auch noch halbwegs verständlich lesbar ist - aber vielleicht gibt es diese Anforderung bei dir ja nicht ...

Ach ja, ich kenne da Anwendungen, die zB. durch den Anwender frei definierbare Zusatzdatenfelder in ähnlicher Form verwalten, nur hat ein Record da neben VARCHAR auch noch Felder vom Typ DECIMAL und DATETIME drinnen und man braucht deswegen kein CAST/CONVERT, muss aber wissen, von welcher Spalte man sich jeweils den Wert holen muss. Macht es nochmal etwas schwieriger aber dafür auch etwas schneller.

bye,
Helmut

[osiris]

Hallo und danke für die Hinweise.

Eine ähnliche Idee wie mit den zusätzlichen Feldern für die Typen DECIMAL und DATETIME hatte ich auch schon. Ich wollte allerdings das Feld 'wert' komplett aus der Relation 'Eintrag_Datenfelder' rausziehen und dann für jeden Datentyp einfach eine neue 1:1 verknüpfte Relation erzeugen, die dann das Feld 'wert' mit dem entsprechend passenden Datentypen enthält. Das erhöht allerdings deutlich die Komplexität des Schemas und ich weiß auch nicht, ob das ein besonders schöner Ansatz ist, da man dann pro Tupel in 'Eintrag_Datenfelder' immer nur eine der 4-5 verknüpften Relationen wirklich benötigt.

[hwoess]

Wie gesagt - diese Flexibilität bedeutet ziemlich viel Overhead, Komplexität und schlechtere Laufzeit. Man sollte sich wirklich sehr gut überlegen, ob sich nicht was anderes findet! Ich habe sowas ansatzweise mal probiert, dann aber gleich wieder bleiben lassen und verwende lieber einfache Strukturen und daraus resultierend einfachere Abfragen, die man auch nach ein paar Jahren noch versteht und bei denen auch die Fehlergefährlichkeit wegen der Einfachheit um einiges weniger ist.

bye,
Helmut