MSSQL verschiedene Datentypen in einer "Spalte"

[Tim T. (tim_taylor)]

Nabend,

ich stehe vor dem Problem Messwerte in eine MSSQL Datenbank zu 
schreiben, pro Datensatz ein Messwert. Die Messwerte können dabei jedoch 
verschiedene Datentypen haben (int, float, time, varchar oder 
varbinary). Ich suche jetzt eine Möglichkeit diese zu speichern, aber 
möglichst ohne dabei den sql_variant Typ zu benutzen oder alles in 
Strings zu verwandeln. Eine Variante die mir dabei durch den Kopf ging, 
war einfach in der Tabelle alle möglichen Datentypen als Feld zu 
definieren aber immer nur eins davon beim Speichern zu beschreiben. Bei 
einer Abfrage würde ich dann nur die Spalten davon ausgeben die nicht 
null sind. Oder gibt es dazu bessere Ideen?

[Florian L. (muut)]

Klingt irgendwie falsch. Wenn der Typ der Messwerte nicht festgelegt 
ist, wie willst du die verarbeiten?
Was sind das für Messwerte?

[Jens G. (jensig)]

Tim T. schrieb:
> schreiben, pro Datensatz ein Messwert. Die Messwerte können dabei jedoch
> verschiedene Datentypen haben (int, float, time, varchar oder
> varbinary). Ich suche jetzt eine Möglichkeit diese zu speichern, aber

Ich glaube, Dein Konzept ist eine komplette Katastrophe. Also am besten 
dieses noch mal überarbeiten ...
Wo kommen die Meßwerte denn her? Bzw. warum ist deren Typ nicht 
festgelegt?
Ansonsten kannste eigentlich jeden Wert in irgendeine CHAR-Typ casten, 
und das dann in der CHAR-Spalte ablegen ...

[Florian S. (sevenacids)]

Ein Messwert, der unterschiedliche Datentypen benötigt? Das wäre mal 
interessant zu erfahren, was hier gemessen wird. Zumal von Integer über 
Fließkommazahl und Datum bis Zeichenfolge alles dabei ist.

Eine mögliche Lösung wäre, sich für einen Datentyp zu entscheiden und 
den erfassten Messwert vor dem Eintragen in diesen zu konvertieren. Ein 
Datum zum Beispiel wäre so ein Fall. Das kann man in einer Datenbank als 
Unix-Timestamp speichern (sofern die Auflösung reicht) und in eine 
solche Umwandeln, sollte das Datum z.B. als Zeichenfolge vorliegen.

[Frank E. (Firma: Q3) (qualidat)]

Damit bist du konzeptionell bei einer relationalen Datenbank falsch, die 
sind von hause aus mehr oder weniger streng typisierend. Strings 
wolltest du ja nicht.

Versuchs mal mit NoSQL, z.B. MongoDB, die sind da nicht so "kleinlich".

[(prx) A. K. (prx)]

Manche Probleme geht man besser von vorne an, nicht vom hinten. Was hier 
bedeutet, die eigentliche Aufgabe zu schildern, nicht nur den zweiten 
Teil einer bereits halb erdachten Lösung. Wenn diese etwas seltsam 
wirkt.

[Ob S. (Firma: 1984now) (observer)]

Tim T. schrieb:

> ich stehe vor dem Problem Messwerte in eine MSSQL Datenbank zu
> schreiben, pro Datensatz ein Messwert. Die Messwerte können dabei jedoch
> verschiedene Datentypen haben (int, float, time, varchar oder
> varbinary). Ich suche jetzt eine Möglichkeit diese zu speichern, aber
> möglichst ohne dabei den sql_variant Typ zu benutzen oder alles in
> Strings zu verwandeln.

> Eine Variante die mir dabei durch den Kopf ging,
> war einfach in der Tabelle alle möglichen Datentypen als Feld zu
> definieren aber immer nur eins davon beim Speichern zu beschreiben. Bei
> einer Abfrage würde ich dann nur die Spalten davon ausgeben die nicht
> null sind.

Wenn du aus unerfindlichen Gründen darauf bestehst, den 
Original-Datentyp unbedingt unverändert beibehalten zu wollen, ist das 
die einzige Möglichkeit. Aber dein "Feld" muß dann doch sehr viele 
Spalten haben...

Kleiner Tip: Liste einfach mal auf, wieviele Gleitkommatypen in MSSQL 
möglich sind. Allein das dürfte dir sagen, dass diese Idee ziemlicher 
Schwachsinn ist.

> Ich suche jetzt eine Möglichkeit diese zu speichern, aber
> möglichst ohne dabei den sql_variant Typ zu benutzen oder alles in
> Strings zu verwandeln.

Zumindest letzteres ist aber eine ziemlich gute Idee. Genau genommen 
sogar die einzige Möglichkeit, um wirklich jeden Datentyp ohne 
Informationsverlust in einer einzigen Spalte speichern zu können. 
Allerdings solltest du weitere Spalte(n) vorsehen, die den jeweils 
verwendeten Datentypen detailliert beschreiben. Sonst könnte nämlich bei 
der Rückwandlung des Strings ein kleines Problem auftauchen...

Normalerweise ist ja die Speicherung kein Selbstzweck, man will später 
irgendwas mit den Daten anfangen. Blöd, wenn sie ohne 
Informationsverlust gespeichert wurden, aber die Information fehlt, was 
eigentlich der ursprüngliche Typ war, um sie wiederum ohne 
Informationsverlust in diesen zurück verwandeln zu können...

[Tim T. (tim_taylor)]

Die Aufgabe ist es verschiedene Messwerte eines DUT abzulegen, je nach 
Prüfsequenz sind das komplett unterschiedliche Sachen. Von verschiedenen 
Spannungen und Strömen, über String Ausgaben von Messsystemen bis hin zu 
Frequenzverläufen ist alles dabei. Im Datensatz steht dabei immer eine 
eindeutige Identifizierung des DUT und die Nummer des Prüfschrittes 
sowie eine Beschreibung der Messgröße. Über die Nummer des Prüfschrittes 
(und eigentlich auch durch die Beschreibung der Messgröße) ist eine 
eindeutige Rekonstruktion des verwendeten Datentyps möglich.

Was die verschiedenen Felder angeht, sind es gar nicht einmal so viele, 
für den Anfang kann der Messwert z.B. 5 verschiedene Datentypen haben. 
Wenn später das Ganze um weitere Datentypen ergänzt werden muss, wird 
einfach eine weitere Spalte mit entsprechendem Datentyp hinzugefügt.

Mir ist an der Stelle schon klar, dass man das eigentlich mit je einer 
Tabelle pro Datentyp macht und in die jeweilige Tabelle dann den 
Primärschlüssel aus der Tabelle mit den Informationen des DUT, die 
Beschreibung der Messgröße und den Messwert ablegt. Wobei ich da dann 
wieder einen Zoo an Tabellen habe.

EDIT: Achja, die MSSQL Datenbank ist gesetzt und nicht verhandelbar. Und 
Strings sind wirklich keine Option.

EDIT2: Und es steht außer Frage das es so wie ich es mir schon überlegt 
habe machbar ist, nur bin ich daran interessiert hier eventuell noch 
bessere Lösungen zu finden (im Rahmen der gesetzten Vorgaben).

[Jens G. (jensig)]

Tim T. schrieb:
> EDIT: Achja, die MSSQL Datenbank ist gesetzt und nicht verhandelbar. Und
> Strings sind wirklich keine Option.

Warum?

> EDIT2: Und es steht außer Frage das es so wie ich es mir schon überlegt
> habe machbar ist, nur bin ich daran interessiert hier eventuell noch
> bessere Lösungen zu finden (im Rahmen der gesetzten Vorgaben).

Ja, dann mach es doch so, wie Du es Dir gedacht hast. Getrennte Spalten 
pro Typ, oder separate Tabellen sind doch nicht so schlecht. Wobei 
getrennte Tabellen (eine pro Datentyp) mM. das bessere Übel sind, weil 
bei einer einzigen Tabelle mit separaten Spalten pro Datentyp viel Platz 
in den Pages frei bleibt.

Tim T. schrieb:
> Wenn später das Ganze um weitere Datentypen ergänzt werden muss, wird
> einfach eine weitere Spalte mit entsprechendem Datentyp hinzugefügt.

"einfach" ist gut - sowas zerklüftet die Tabelle u.U. ganz gründlich, 
weil eine neue Spalte nicht einfach in bereits belegte Pages integriert 
werden kann. Wie mysql das aber konkret handhabt, weiß ich jetzt nicht. 
Kann sein, daß dies erstmal kein Problem darstellt, solange bereits 
existierende Rows keine Werte in die neuen Spalten bekommen. ...

[Tim T. (tim_taylor)]

Jens G. schrieb:
> Tim T. schrieb:
>> EDIT: Achja, die MSSQL Datenbank ist gesetzt und nicht verhandelbar. Und
>> Strings sind wirklich keine Option.
>
> Warum?

Weil die MSSQL Server Infrastruktur noch andere Sachen übernimmt und 
daher alternativlos gesetzt wurde (auch nicht meine Entscheidung).
Und Strings (XML) in der Datenbank für die Messwerte sind der 
Ist-Zustand, bringen aber diverse ihre Nachteile mit sich.

> Tim T. schrieb:
>> Wenn später das Ganze um weitere Datentypen ergänzt werden muss, wird
>> einfach eine weitere Spalte mit entsprechendem Datentyp hinzugefügt.
>
> "einfach" ist gut - sowas zerklüftet die Tabelle u.U. ganz gründlich,
> weil eine neue Spalte nicht einfach in bereits belegte Pages integriert
> werden kann. Wie mysql das aber konkret handhabt, weiß ich jetzt nicht.
> Kann sein, daß dies erstmal kein Problem darstellt, solange bereits
> existierende Rows keine Werte in die neuen Spalten bekommen.

Das ist kein Problem, nach jeder (nicht so häufigen) Erweiterung der 
Datentypen kann man auch eine offline Reorganisation fahren. Und alle 
Messwert Datentypen haben einen Default von NULL, sind also bei einer 
Erweiterung unkritisch.

[Chris K. (kathe)]

Tim T. schrieb:
> Die Aufgabe ist es verschiedene Messwerte eines DUT abzulegen, je nach
> Prüfsequenz

Think different,  Du hast verschiedene Prüfsequenzen... Je nach Sequenz, 
die daten in eine eigene Tabelle... somit eindeutig... Oder du kannst 
nochmals von vorne anfangen.

[Tim T. (tim_taylor)]

Chris K. schrieb:
> Tim T. schrieb:
>> Die Aufgabe ist es verschiedene Messwerte eines DUT abzulegen, je nach
>> Prüfsequenz
>
> Think different,  Du hast verschiedene Prüfsequenzen... Je nach Sequenz,
> die daten in eine eigene Tabelle... somit eindeutig... Oder du kannst
> nochmals von vorne anfangen.

Stimmt, das hatte ich nicht wirklich auf dem Schirm. Einfach die 
Ergebnisse der Prüfung eines DUT in die Spalten einer Zeile schreiben. 
So hätte ich in der Tabelle dann pro Zeile jeweils die komplette 
Prüfsequenz eines DUT und in der ganzen Tabelle dann die Ergebnisse 
aller DUT gleicher Art.

[Ein T. (ein_typ)]

Tim T. schrieb:
> Mir ist an der Stelle schon klar, dass man das eigentlich mit je einer
> Tabelle pro Datentyp macht und in die jeweilige Tabelle dann den
> Primärschlüssel aus der Tabelle mit den Informationen des DUT, die
> Beschreibung der Messgröße und den Messwert ablegt. Wobei ich da dann
> wieder einen Zoo an Tabellen habe.

So ist das nunmal bei relationalen Datenbanken: es gibt Relationen, 
mitunter sogar viele.

> EDIT: Achja, die MSSQL Datenbank ist gesetzt und nicht verhandelbar. Und
> Strings sind wirklich keine Option.

Sorry, aber Dein Design ist kaputt. Mein Rat wäre, es zu reparieren, 
entweder indem Du Frank E.'s Tipp umsetzt, eine NoSQL-Datenbank zu 
benutzen -- wobei mein Tipp an dieser Stelle vermutlich eher Elastic- 
oder OpenSearch wäre, aber sei's drum -- oder indem Du Dir ein 
ordentliches Design für Deine relationale SQL-Datenbank überlegst, das 
zwangsläufig auf mehrere Tabellen hinausläuft.

> EDIT2: Und es steht außer Frage das es so wie ich es mir schon überlegt
> habe machbar ist, nur bin ich daran interessiert hier eventuell noch
> bessere Lösungen zu finden (im Rahmen der gesetzten Vorgaben).

Irgendwie erinnert mich Deine Vorgehensweise stark an den Namensgeber 
Deines Nickname, der will ja auch immer mit dem Kopf durch die Wand. 
Womöglich sind diese Ähnlichkeiten ja kein Zufall... ;-)

[Gustav G. (gustavgggg)]

Jens G. schrieb:
> Ich glaube, Dein Konzept ist eine komplette Katastrophe. Also am besten
> dieses noch mal überarbeiten

Das halte ich so erstmal für zu Pauschal. Beispielsweise gibt es schon 
Fälle, wo das Sinn machen kann. Zum Beispiel Messdaten unterschiedlicher 
Messinstrumente in einer Tabelle zur Archivierung und Auswertung 
sammeln. Manche DBMS unterstützen Unions aber ein Weg wäre auch für 
jeden Datentyp eben eine Spalte anzulegen und den Rest eben auf NULL 
lassen.

Man kann es auch mit weiteren Tabellen für jeden Typ machen und per 
Foreign Key Constraint aber das ist Geschmacksache und kommt drauf an 
wie dein Schema insgesamt aussehen soll.

[Udo S. (urschmitt)]

Tim T. schrieb:
> Über die Nummer des Prüfschrittes
> (und eigentlich auch durch die Beschreibung der Messgröße) ist eine
> eindeutige Rekonstruktion des verwendeten Datentyps möglich.

Wenn das eh rekonstruiert werden muss um es irgendwie wieder zu 
verarbeiten dann nimm entweder ein String oder ein blob.
Hilfreicher wäre zumindest eine weitere Spalte mit dem Datentyp, statt 
das implizit über Gerätetyp und Prüfschritt zu definieren.

So klingt das für mich nach einem maximal unhandlichen Design.

[Steve van de Grens (roehrmond)]

Tim T. schrieb:
> Achja, die MSSQL Datenbank ist gesetzt und nicht verhandelbar. Und
> Strings sind wirklich keine Option.

Dann halt Byte Arrays.

Aber lass dich warnen: Strings (varchar) sind an vielen Stellen viel 
einfacher zu verwenden. Zur Not würde ich die Daten lieber in base64 
codieren, anstatt rohe Byte Arrays zu verwenden.

[Tim T. (tim_taylor)]

Udo S. schrieb:
> Tim T. schrieb:
>> Über die Nummer des Prüfschrittes
>> (und eigentlich auch durch die Beschreibung der Messgröße) ist eine
>> eindeutige Rekonstruktion des verwendeten Datentyps möglich.
>
> Wenn das eh rekonstruiert werden muss um es irgendwie wieder zu
> verarbeiten dann nimm entweder ein String oder ein blob.
> Hilfreicher wäre zumindest eine weitere Spalte mit dem Datentyp, statt
> das implizit über Gerätetyp und Prüfschritt zu definieren.
>
> So klingt das für mich nach einem maximal unhandlichen Design.

Nö, ansich recht easy, wenn in der jeweiligen Datentyptabelle eben nur 
der eine Datentyp vorkommt und in den anderen Datentyptabellen eben 
nicht.
Und da der jeweilige Prüfschritt ja auch einen Namen und eine 
Beschreibung hat, ist der Rest selbsterklärend.

Tim T. schrieb:
> Und Strings (XML) in der Datenbank für die Messwerte sind der
> Ist-Zustand, bringen aber diverse ihre Nachteile mit sich.

Also an der Stelle bin ich schon, nur für die Weiterverarbeitung ist das 
alles andere als Ideal. Darum ja die Idee die Daten in nativen SQL Typen 
abzulegen.