Ich würde es mit getrennten Indizes machen. Das ist flexibler.
Erklär mal bitte. Ist der kombinierte Index über den Zeitraum und Messstationen nicht besser, als nur über den Zeitraum? Den Index über die ValueID wird man
imho nie benutzen, oder irre ich mich?
Ein kombinierter Index ist naheliegend, lässt sich durch das RDBMS bzw. den Optimizer aber oftmals nicht so vielseitig nutzen.
Das Thema ist sehr
DB spezifisch, vermutlich sogar (Optimizer)Version-spezifisch.
Einzeln aufgebaute Indizes werden durch die Optimizer idR besser nach Bedarf zusammengesetzt bzw. abgegriffen, also wirklich verwendet, als Kombi-Indizes. Deren Aufbau und Nutzen ist halt viel spezifischer.
Die Verwendung / Filterung nach Meßstation halte ich für sehr naheliegend. Auch wenn der Kunde was anderes behauptet.
Letztlich ist das Indexthema aber sekundär, weil man es unabhängig von der Logik mit ein paar Handgriffen variieren und testen kann, notfalls sogar auf einem Produktivsystem.
mal ne blöde Frage, wieso muessen die Daten denn in festen Zeitabständen gespeichert werden?
man könnte doch auch einfach einen Datensatz speichern wenn der Messwert einen gegeben Wert vom letzten gespeicherten Wert abweicht,
dann kann man einerseits die Daten im Sekundentakt reinholen , ohne die
DB mit Abermillionen von gleichen Werten sich widerholenden aufzublasen
man haette dann die granularitaet Abnormalitaeten sekundengenau zu untersuchen
Nachteil: würde aber die Auswertungen etwas Komplizierter machen
mfg Hannes
Das ist eine prima Sache.
Wenn Anzahl der Messwerte und Toleranz gespeichert werden, kann man die Daten wenn es sein muss (>Auswertung/Export/Archiv) auch rekonstruieren (mit Toleranzverlust natürlich). Vermutlich sogar transparent on the fly per View bspw.