Hallo, was für Möglichkeiten habe ich, um Variablenwerte verschiedenen Datentyps in einer einzigen SQL-Tabelle zu speichern? Als Datentypen habe ich: Bool, Integer (8/16/32/64 Bit signed/unsigned), und Gleitkomma (32/64Bit). Ggf. sollen auch noch Zeichen/Zeichenketten möglich sein. Meine Idee wäre, eine Tabelle mit Variablennamen und dem Datentyp anzulegen, und dann eine weitere Tabelle mit den aktuellen Werten (mit einer Referenz-ID auf die Konfigurationstabelle). Wobei ich dann für die Bool und Integer-Variablen ein Spalte mit BIGINT, und für die Gleitkomma eine Spalte mit 64Bit-Real anlegen würde. Dann müsste ich bei jeder Wertabfrage aber über zwei Tabellen kombinieren. Bin ich da auf dem richtigen Weg, oder gibt es bessere / andere Lösungen?
Thomas W. schrieb: > was für Möglichkeiten habe ich, um Variablenwerte verschiedenen > Datentyps in einer einzigen SQL-Tabelle zu speichern? Mehrere Spalten verschiedenen Typs wäre die nahe liegende Lösung. Aber was ist denn der Sinn des Ganzen?
Thomas W. schrieb: > was für Möglichkeiten habe ich, um Variablenwerte verschiedenen > Datentyps in einer einzigen SQL-Tabelle zu speichern? Jede Spalte einer Tabelle kann einen anderen Datentyp haben. Das ist so trivial, dass ich mir nicht sicher bin, ob du das meinst. Willst du verschiedene Typen in der gleichen Spalte speichern? Da wärs vielleicht sinnvoller, nicht die Lösung sondern das Problem zu nennen. Weil es vielleicht ein falscher Ansatz sein könnte.
:
Bearbeitet durch User
Thomas W. schrieb: > was für Möglichkeiten habe ich, um Variablenwerte verschiedenen > Datentyps in einer einzigen SQL-Tabelle zu speichern? SQLite benutzen. Oder alles in Strings umwandeln. Oder mehrere Spalten benutzen. > Meine Idee wäre, eine Tabelle mit Variablennamen und dem Datentyp > anzulegen, und dann eine weitere Tabelle mit den aktuellen Werten (mit > einer Referenz-ID auf die Konfigurationstabelle). Warum zwei Tabellen? Eine genügt.
der "number" datentyp sollte das abdecken.
1 | Positive numbers in the range 1 x 10-130 to 9.99...9 x 10125 with up to 38 significant digits |
2 | |
3 | Negative numbers from -1 x 10-130 to 9.99...99 x 10125 with up to 38 significant digits |
oder, wie schon vorgeschlagen, mehrere spalten. aber ohne die information was du eigentlich machen willst ist das nur spekulation.
Ich möchte im Hintergrund mit einem Programm Daten einsammeln, und die Werte in einer Datenbank schreiben. Abgerufen werden sollen diese über eine Webseite. Ggf. sollen einzelne Werte auch noch archiviert werden, aber erst mal geht es um die Darstellung der Aktualwerte. Ich könnte auch pro Datentyp (Int, Float, String) eine eigene Tabelle anlegen, dann hätte ich keine leeren Spalten in meiner Tabelle.
Thomas W. schrieb: > Ich möchte im Hintergrund mit einem Programm Daten einsammeln, und die > Werte in einer Datenbank schreiben. Und wieso ändert das sammelnde Programm dauernd den Datentyp?
Wolfgang schrieb: > Und wieso ändert das sammelnde Programm dauernd den Datentyp? Es ändert sich nicht dauernd. Es wird einmal festgelegt, bzw. kann vom Benutzer konfiguriert werden. Er könnte aber theoretisch auch den Datentyp einer bestehenden Variablen ändern.
> vom Benutzer konfiguriert
Das Problem bei mehreren Tabellen -- ab und zu machen die Datenbanken
total hirnrissige Joins, die ewig dauern.
Normalerweise kein Thema. Da legt der Admin halt andere Indizes an. Aber
wenn der Endbenutzer die Datenbank konfiguriert, solltest du alles
vermeiden, was die Automatismen der Datenbank falsch machen können.
> Ich möchte im Hintergrund mit einem Programm Daten einsammeln, und die > Werte in einer Datenbank schreiben. Abgerufen werden sollen diese über > eine Webseite. Ggf. sollen einzelne Werte auch noch archiviert werden, > aber erst mal geht es um die Darstellung der Aktualwerte. rrd
1N 4. schrieb: > rrd kommt drauf an. was für werte? was heißt "sollen dargestellt werden"? vielleicht braucht der TO gar keine datenbank, sondern nur eine plaintext datei, die "im browser" dargestellt wird. wenn rrd, wäre vielleicht munin eine lösung?
Es gibt auch den - zugegeben etwas unsauberen - Weg, verschiedene Datentypen im gleichen Feld abzulegen. Dann schreibt man in ein Feld den Datentyp (als Token oder Kürzel) und in einem anderen Feld dessen Inhalt/Wert in Textform. Die Typwandlung erfolgt dann in der nutzenden Anwendung beim Einschreiben bzw. Auslesen. Das benötigt man in manchen Fällen, wo sehr unterschiedliche Infos zu einem Objekt (z.B. Auftragsverwaltung) auftreten können.
Thomas W. schrieb: > Ich möchte im Hintergrund mit einem Programm Daten einsammeln, und die > Werte in einer Datenbank schreiben. Gibts eine Grund, weshalb das unbedingt eine SQL Datenbank sein muss? Nach komplexer SQL-Abfragetechnik riechst das ja nicht. Wenn du einfach nur grosse Mengen indizierter Daten speichern musst, käme vielleicht auch die Berkeley DB in Frage. Die speichert Paare aus Schlüssel und nicht weiter strukturierten Daten - das aber recht effizient. Die Daten bestünden dann dann aus einem Typ-Tag und dem eigentlichen Wert.
:
Bearbeitet durch User
Nach 13 Posts eiert man immer noch beim Lokalisieren des Problems rum. Der Poster will sich auf eine SQL Datenbank festlegen, hat aber Null Ahnung was deren Moeglichkeiten sind. Da die Verbindung MySQL - Website schon vorhanden ist, kann ein erste Loesung den Typ String abspeichern, Je Eintrag eine Zeile, da erscheint die Zahlen Sequenz als String.
A. K. schrieb: > Wenn du einfach > nur grosse Mengen indizierter Daten speichern musst, käme vielleicht > auch die Berkeley DB in Frage. Redis, Elasticsearch, MongoDB, ... ;-)
Es macht zwar keinen Sinn, aber vielen Datenbanken haben ein Binary Datentyp. z.b. Varbinary. Da kann man jeden Datentype drin speichern. So lange man in der Datenbank mit dem Werten nicht rechnen muss, sollte das funktionieren.
Ich erlaube mir mal 'ne blöde Frage: Sind's wirklich float-Werte oder Werte mit einer fixen Zahl an Nachkommastellen? Weil dann wär's einfach, Du speicherst einfach Integerwerte und schiebst das Komma rum. ;)
Heinz L. schrieb: > Ich erlaube mir mal 'ne blöde Frage: Sind's wirklich float-Werte oder > Werte mit einer fixen Zahl an Nachkommastellen? Weil dann wär's einfach, > Du speicherst einfach Integerwerte und schiebst das Komma rum. ;) Oder machst es wie vorgesehen mit decimal: https://dev.mysql.com/doc/refman/5.5/en/fixed-point-types.html
Thomas W. schrieb: > Wolfgang schrieb: > >> Und wieso ändert das sammelnde Programm dauernd den Datentyp? > > Es ändert sich nicht dauernd. Es wird einmal festgelegt, bzw. kann vom > Benutzer konfiguriert werden. Er könnte aber theoretisch auch den > Datentyp einer bestehenden Variablen ändern. Mit einem RDBMS wie Postgresql fallen mir da mindestens drei Möglichkeiten ein, aber für mich hört sich das erstmal nach einer verkorksten Idee an. Die Idee der Typfestlegung bei Datenbanken ist, daß man damit, soweit es irgend möglich ist, konsistente und korrekte Daten erzwingen kann -- manche gehen sogar so weit, zusätzliche Constraints für Wertebereiche, referentielle Integrität etc.zu erzwingen. Nun kann man diese Integritätstests zwar umgehen, indem man etwa die Daten als Text oder Varchar speichert und dann -- wenn man zum Beispiel mit den Daten rechnen will -- ggf. eine View darauflegt, welche die Daten bei der Abfrage in das gewünschte Format konvertiert. Oder, indem man die Daten gleich in einem JSON- oder XML-Datentyp speichert. Aber eigentlich ist es nicht der Sinn der Sache, solche Dinge zu machen oder Datentype nach dem Anlegen der Tabelle zu ändern. (Auch wenn die RDBMS für besondere Fälle entsprechende Befehle dafür anbieten.) Insofern würde ich Dir empfehlen, entweder noch einmal über Dein Design nachzudenken oder vielleicht noch etwas genauer zu beschreiben, was Du eigentlich vorhast. Viel Erfolg!
Ich weiß nicht warum das für euch so absurd ist. Ich habe z.B. Energiemessgeräte die den Energie-Zählwert in Wh als 64 Bit Ganzzahl ausgeben, aber auch die aktuellen Werte wie Ströme, Spannung und Leistungen eben im Gleitkomma-Format. Bei Visualisierungen wie Siemens WinCC gelangen auch Daten unterschiedlichen Datentyps in einer SQL-Datenbanktabelle. Aber dort soweit ich das sehen konnte werden die Daten in irgendeiner Art komprimiert in der DB gespeichert. Evtl. ist das auch nur ein Byte-Blob mit einer Typkennung und dann den Rohdaten, so wurde es hier ja auch schon erwähnt.
Thomas W. schrieb: > Ich weiß nicht warum das für euch so absurd ist. Weil es eine Vergewaltigung von SQL ist. SQL ist eine Abfragesprache relationaler Datenbanken, und die ist infolgedessen typbezogen. Und weil du nicht der Erste wärst, der, nur mit einem Hammer ausgestattet, jedes Problem als Nagel betrachtet. Weshalb man gerne etwas tiefer fragt. Was nicht selten den Fragesteller etwas frustriert, der einfach nur wissen will, welchen Nagel man am besten in das M6 Gewinde haut.
:
Bearbeitet durch User
>Hallo, >was für Möglichkeiten habe ich, um Variablenwerte verschiedenen >Datentyps in einer einzigen SQL-Tabelle zu speichern? ... >Ich weiß nicht warum das für euch so absurd ist. >Ich habe z.B. Energiemessgeräte die den Energie-Zählwert in Wh als 64 >Bit Ganzzahl ausgeben, aber auch die aktuellen Werte wie Ströme, >Spannung und Leistungen eben im Gleitkomma-Format. Ja, dafür macht man einfach eine Tabelle mit 4 Spalten. Eine (big)integer for die Energie, und je eine float für Strom, Spannung, Leistung. Warum ist diese einfache Lösung für Dich so absurd?
Jens G. schrieb: > Ja, dafür macht man einfach eine Tabelle mit 4 Spalten. Oder halt alternativ eine entsprechend dimensionierte DECIMAL Spalte.
Jens G. schrieb: > Ja, dafür macht man einfach eine Tabelle mit 4 Spalten. > Eine (big)integer for die Energie, und je eine float für Strom, > Spannung, Leistung. > Warum ist diese einfache Lösung für Dich so absurd? Formal ging das natürlich. 3. Normalform wäre das aber nicht. -> Ein Haufen Spalten und davon enthält nur immer eine den gesuchten Wert. Die anderen bestenfalls einen default Wert. -> Steht in einer Spalte ein default Wert weiß man nicht, ob es auch tatsächlich einer ist. Z.B. default = 0,0. Das könnte auch ein gültiger Wert sein. Alternativ: null. Das sollte aber grundsätzlich über das DB Design verhindert werden: https://technet.microsoft.com/de-de/library/ms189265(v=sql.105).aspx -> Kommt eine Spalte hinzu muß das Schema und SQL Statements angepaßt werden. -> Ändert sich der Typ eines Wertes müssen alle betroffenen Werte in eine andere Spalte kopiert werden. Ich bevorzuge die Lösung mit einer Spalte für Werte und einer weiteren für deren Tpy. Die (De-)Serialisierungslogik befindet außerhalb der DB.
DBD schrieb: > 3. Normalform wäre das aber nicht. Und das begründest du wie? Deine aufgezählten Punkte widerlegen das nicht.
@ DBD (Gast) >-> Ein Haufen Spalten und davon enthält nur immer eine den gesuchten >Wert. Die anderen bestenfalls einen default Wert. >-> Steht in einer Spalte ein default Wert weiß man nicht, ob es auch >tatsächlich einer ist. Z.B. default = 0,0. Das könnte auch ein gültiger Bis jetzt ist mir immer noch nicht ganz klar, ob alle vier Werte gleichzeitig auftreten, oder immer nur einer (bei letzterem würde ich den Sinn vermutlich nicht verstehen). Und wenn es letzteres wäre - der Defaultwert für solche nicht gefüllten Werte wäre dann eben NULL (also eben kein bzw. unbekannter/undefinierter Wert), und nicht 0,00 oder sowas. >Wert sein. Alternativ: null. Das sollte aber grundsätzlich über das DB >Design verhindert werden: >https://technet.microsoft.com/de-de/library/ms1892... Sagt wer? Dein Link? Das gilt nur in bestimmten Fällen, aber nicht grundsätzlich. NULL ist schließlich kein Schreckgespenst .... >-> Kommt eine Spalte hinzu muß das Schema und SQL Statements angepaßt >werden. Ja und? Dafür nimmst Du dann wohl lieber Performanceprobleme durch Joins bei Abfragen in Kauf? Zusätzlich muß sich nun die Anwendungslogik um die Datentypen kümmern, da die DB sich ja nun nicht dieser Datentypen bewußt ist (die Datentypen stehen ja nur als Wert in der Zusatztabelle, ist also kein Datentyp im SQL-Sinne). Das Problem mit den Erweiterungen hat man immer. SQL und Anwendungslogik muß man so oder so anpassen. >-> Ändert sich der Typ eines Wertes müssen alle betroffenen Werte in >eine andere Spalte kopiert werden. Das dürfte eine äuserst seltener Anwendungsfall sein. Betrachte ich als an den HAaren herbeigezogen.
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.