Hmmm… ganz schön viel Redundanz bei der Datenspeicherung. Nach einigen Monaten oder gar Jahren kommen da bei einem Einfamilienhaus schnell mal einige Gigabyte an Datenbank zusammen. Bei mir ca. 4 GB DB-File bei 24 Monaten, die erstmal schnell genug gehandelt werden müssen! Da wird mir bei den „zusatzdaten“ bzw. den deshalb erforderlichen komplexeren Abfragen doch etwas mulmig zumute.
Redundanz deshalb:
Es ist zwar sicher auf den ersten Blick recht verlockend, „für Verwendung fertige Daten“ direkt an den Records zu speichern (counter, duration, lasttime usw.), aber letztlich sind diese Sekundärwerte beim Auswerten (außer vielleicht für die Anzeige von Einzelgraph-Diagrammen) kaum wirklich brauchbar.
Ursache: Die Ereignisse verschiedener Sensoren (oder anderer Auswerte-Aufgaben wie „Tagesgrenze“, „Sturmanfang“ usw) liegen quasi ASYNCHRON zu den schon gespeicherten Daten.
Wenn ich also den Daten-Zustand zu einem (beliebigen, von mir „willkürlich“ definierten) Zeitpunkt abfragen können will, werde ich kaum einmal „genau dazu passende“ (und somit linear auslesbare) Zeitstempel finden, weder als erster, noch als letzter Zpeicherzeitpunkt.
Wenn ich aber ergo ohnehin berechnen muß, welcher Wert zu einem Abfragezeitpunkt gültig war, reicht ein viel simpleres Datenmodell, das sozusagen die kleinste Form des Speicherverbrauchs (=Basis der info-theoretisch schnellstmöglichsten Abfragen) darstellt:
Quasi als Stack streng chronologisch gespeicherte Records mit
- ObjectID (also der Sensor oder die Instanz usw.)
- Datenwert
- Zeitstempel (=„gültig ab“)
- disabled-Flag (=„Gültigkeit erloschen“ für letzten Eintrag zeitlich begrenzt gelieferter Werteperioden, = z.B. Ausschalt-Ereignis)
Neue Records IMMER nur, wenn
- Wert zu Vorwert geändert ist (onchange), oder
- Wert der erkennbar letzte gültige einer Werte-Periode ist („gültig ab“ ist dann Endezeitpunkt der Periode)
Alles andere inkl. Errechnung des gültigen Wertes zum Abfragezeitpunkt macht dann eine Datenbankfunktion, parametrisiert mit ObjectID und gewünschten Abfragezeitpunkt.
Diese liefert den aus den Zustandsdaten generierten Wert zum Abfragezeitpunkt, der ja identisch ist mit dem Wert am letzten „davorliegenden“ Gültigkeits-Zeitstempel.
Ist dort das disabled-Flag gesetzt, gilt quasi der Sonderfall „kein gültiger Wert zum abgefragten Zeitpunkt vorhanden“.
Einen guten Index auf die entsprechenden Spalten vorausgesetzt, sind dann quasi-lineare Abfragen auch bei großen Wertemengen völlig schmerzfrei!
Sicher, für Diagramm-Ausgaben, die zB per Spline-Funktionen Kurven mittels echter Stützwerte „rund machen“, ist das weniger geeignet, da die sich nicht ändernde Werte fehlen. Das bisherige Modell hat diese Zwischenwerte aber auch nicht mehr(!), höchstens einen Zähler als „Gewichtung“ des letzten Wertes, was auch arg nach hinten los gehen kann! Schon die zeitliche Synchronisierung mehrerer Kurven in einem Diagramm dürfte aber ohne „Vergleichszeitpunkte“, also „gültige/hochgerechnete Werte zum Vergleichszeitpunkt“ problematisch werden.
ABER derartige Datenmodelle eignen sich für fast alles andere, inkl. Vergleiche verschiedenster Werte zu einem Zeitpunkt! Denn sie geben den SystemZUSTAND zu einem Zeitpunkt wieder (und werden deshalb „Zustandsdatenmodelle“ genannt). Und der Systemzustand (interpretiert zB durch den zeitlichen Zustand einer Variable) ändert sich eben nur bei Werteänderung oder wenn dessen Gültigkeit endet. Redundanzfreier gehts nimmer, um zB. nachträglich auf Verbrauchswerte o.ä. zuzugreifen!
Wer nun fragt, was mit „entfallenen“ Werten ist, also Aufzeichnungsfehler, weil Signal nicht übertragen wurde usw.: Was nicht vorhanden bzw. erfasst worden ist, kann auch nachträglich nicht „hineininterpretiert“ werden. Auch nicht durch Esoterik o.ä. 
Schlimmstenfalls werden Werte „verschleift“, weil Zwischenwerte fehlen. Aber WAS erfasst wurde, ist in jedem Fall ausles- und auswertbar!
…das nur mal als Ideenfutter für evtl. Weiterentwicklungen, wenns denn mal langsam wird mit zunehmender Datenmenge und Auswerte-Komplexität.
Gruß Gerd