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?
Klingt irgendwie falsch. Wenn der Typ der Messwerte nicht festgelegt ist, wie willst du die verarbeiten? Was sind das für Messwerte?
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 ...
:
Bearbeitet durch User
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.
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".
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.
:
Bearbeitet durch User
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...
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).
:
Bearbeitet durch User
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. ...
:
Bearbeitet durch User
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.
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.
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.
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... ;-)
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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.