Verdichtungstabellen für Messwertarchiv erstellen

[Medium]

Das ist doch gar keine so doofe Lösung. Danke euch erneut. Ich glaube, das wird richtig gut!

[jobo]

Zitat von Sir Rufo:

Die Lösung heisst, dass du alle Werte in der Datenbank als UTC speicherst und vor jeder Abfrage die Zeitpunkte immer von lokal nach UTC umwandelst

Ich bin kein MySQL Spezialist, aber MySQL speichert intern sowieso UTC. Beim Schreiben und Lesen werden die Werte gemäß Sessioneinstellung des Clients geändert. Das kann mindestens konfigurationsabhängig (client) sein, aber auch per session/sql geändert werden.
An der Stelle würde ich jetzt mal ein paar Blicke in die Doku werfen, um unnötige oder fehlerhafte Konvertierung zu vermeiden.
Soetwas wird bei einer "vollwertigen" Clientinstallation ggF. auch bereits schon berücksichtigt. Wirft man da nur eine DLL rein, sieht es vielleicht anders aus.

[Dejan Vu]

Falls die Daten in 'Echtzeit' erfasst werden, könnte der Timestamp auch vom Server erstellt werden. Das ist dann sinnvoll, wenn die Daten über ihren Zeitstempel irgendwie korreliert werden sollen. Damit kann dann auch ein PC in Timbuktu mal total falsch laufen oder die Zeitzone verstellt sein.

Natürlich ist das etwas heikel und bringt nur etwas, wenn die Daten wirklich sofort zum Server geschickt werden.

[Sir Rufo]

Zitat von Dejan Vu:

Falls die Daten in 'Echtzeit' erfasst werden, könnte der Timestamp auch vom Server erstellt werden. Das ist dann sinnvoll, wenn die Daten über ihren Zeitstempel irgendwie korreliert werden sollen. Damit kann dann auch ein PC in Timbuktu mal total falsch laufen oder die Zeitzone verstellt sein.

Natürlich ist das etwas heikel und bringt nur etwas, wenn die Daten wirklich sofort zum Server geschickt werden.

Es kommt gar nicht mal so auf den PC an, denn der Zeitstempel wird ja von dem Messgerät geliefert. Und nun kommt es darauf an, wie genau die Uhr dort ist und welche Zeitzone dort eingestellt ist.

[Medium]

In diesem Fall liefern die Geräte nicht die Uhrzeit. Das wäre auch wirklich nicht schön, so um die 200-300 davon sekundengenau zu synchronisieren. Nein, federführend soll hier der messende PC sein. Das wird ein hübscher 19"er im klimatisierten Serverraum (inkl. Backup-Gerät - hoffentlich macht die MySQL Redundanz die hier besprochenen Dinge mit - noch nicht getestet). Insbesondere bei den Werten, die ich langsamer als sekündlich lese will ich so sicherstellen, dass ich brav auf den Intervallgrenzen lese und schreibe. In der Praxis werden hier wohl nur sekündlich, minütlich und stündlich relevant. Und wenn ein paar Werte ein paar Millisekunden nach 12:30:00 erst eintreffen, will ich die bitte auch noch auf der glatten Uhrzeit haben. So genau braucht das nicht. (Die sekündlichen Werte sind auch nur gefordert, damit kürzere Spitzen nicht im Sampling untergehen.)

[Dejan Vu]

Zitat von Sir Rufo:

Es kommt gar nicht mal so auf den PC an, denn der Zeitstempel wird ja von dem Messgerät geliefert. Und nun kommt es darauf an, wie genau die Uhr dort ist und welche Zeitzone dort eingestellt ist.

Also bei uns damals nicht. Das Messgerät hat die Messergebnisse geliefert und der PC (die SW) dann die Uhrzeit dazu gepackt und im Server abgelegt. Dann sind wir auf die Idee mit der Serverzeit gekommen, waren aber noch so dämlich, und haben die jeden PC 1x pro Minute abfragen lassen, damit sich der dann synchronisiert.

Zum Schluss haben wir den Server den Zeitstempel eintragen lassen.

PS: Wenn (und falls) mySQL mit sekundengenauen Uhrzeiten Probleme haben sollte (sofern es wirklich wichtig ist, ob eine Messung um 13:23:47,000 und nicht um 13:22:49,99997 erfolgt ist), würde ich die Uhrzeit als Ganzzahl speichern.

Du kannst Dir eine nette kleine 'Uhrzeit'-Tabelle bauen. Mit genau 86400 Einträgen. Dort stehen dann neben ID und der sekundengenauen Uhrzeit noch alle möglichen Informationen drin, z.B. die Stromkosten zudem Zeitpunkt, oder Frühschicht oder Spätschicht, oder, oder, oder. Alles, was einem zu einer Uhrzeit so einfallen kann. (Stichwort: Uhrzeit-Faktentabelle).

In deiner Messhistory-Tabelle steht dann nicht die Uhrzeit, sondern die ID (also eigentlich, wie viele Sekunden ab Mitternacht).

Wenn Du dann das Datum noch als Faktentabelle ablegst und anstatt dem Datum die Datums-ID verwendest, dann bist Du schon ziemlich nahe an einem winzig kleinen DWH.