Sensordaten aus einer Tabelle nach Datum sortiert ausgeben.

[hruendel]

Hallo,

habe eine Tabelle in der ich die Messdaten von mehreren Sensoren aufnehme (wie Wetterstation). die Anzahl der Sensoren kann variieren, deswegen eine zentrale Tabelle mit Messdaten. Wenn ich die Sensoren Abfrage kann ich die gleiche Systemzeit bei allen Einträgen reinschreiben. Das ist eine Vereinfachung damit man zu mindestens denselben Zeitpunkt hat. So etwas wie LEFT JOIN nur halt nach timestamp gruppiert.

Hat einer die Vorstellung, wie man eine Anfrage formuliert damit man eine Art Statistik mit mehreren Sensoren aus derselben Tabelle für denselben Zeitpunkt auswählt?

Vereinfacht sieht die Tabelle so aus:

Vorhandene Tabelle (test.measurement_data):

id | sensor | value | timestamp
-------------------------------------------
1 | 1 | 10°C | 2016-12-05
-------------------------------------------
2 | 2 | 20°C | 2016-12-05
-------------------------------------------
3 | 3 | 30°C | 2016-12-05
-------------------------------------------
4 | 1 | 11°C | 2016-12-06
-------------------------------------------
5 | 2 | 21°C | 2016-12-06
-------------------------------------------
6 | 3 | 31°C | 2016-12-06


Ausgabe:

timestamp | sensor 1 | sensor 2 | sensor 3
--------------------------------------------------------------
2016-12-05 | 10°C | 20°C | 30°C
--------------------------------------------------------------
2016-12-06 | 11°C | 21°C | 31°C

Man kann natürlich mehrere Schleifen bilden, MySQL ist aber so flexibel, dass man es bestimmt eleganter lösen kann.

[hausl]

Google mal nach "mysql pivot" ist es sowas, das du suchst?

zB http://stackoverflow.com/questions/1...ber-of-columns

[Andreas]

Im Grunde nicht... du selektierst alle Daten, die du brauchst, sortierst nach Datum, läufst mit einer Schleife drüber und gibst sie nach Datum gruppiert aus...

Irgendwie so (ungetestet):

<?php
$sql = "select id, sensor, value, timestamp FROM measurement_data ORDER BY timestamp";
$result = $db->query($sql);
?>
<table>
<thead>
<tr>
<th>timestamp</th>
<th>sensor1</th>
<th>sensor2</th>
<th>sensor3</th>
</tr>
</thead>
<tbody>
<?php
$lastTimestamp = false;
while($row = $result->fetchRow()) {

    if($lastDate != $row["timestamp"]) {
        if($lastTimestamp !== false) {
            echo "</tr>";
        }
        echo "<tr><td>".$row["timestamp"]."</td>";
    }

    echo "<td>".$row["value"]."</td>";

}
if($lastTimestamp !== false) {
    echo "</tr>";
}
?>
</tbody>
</table>

Mit MySQL geht es natürlich auch...

[hausl]

hruendel

Irgendwie so (ungetestet):

Siehe dazu auch dieses Beispiel: https://php-de.github.io/jumpto/grup...h/#beispiel-1b

[hruendel]

Ich vermute, ich werde pro Sensor eine Spalte durch PHP-Skript anlegen müssen wenn ich die in der Software anlege. Dann habe ich pro zeile ein datastamp und die Messwerte der Sensoren. Wenn ich den Sensor in der Software lösche werde ich die Spalte löschen. So wird es auf jeden Fall performanter. Wenn man 10.000 Messwerte hat wird das Ding ewig rattern müssen. Eine Lösung muss es für das Problem wohl geben. Die wird hier aber eher nicht passen. Habe schon seit einer Woche probiert, keine vernünftige Lösung gefunden.

[hausl]

Ich vermute, ich werde pro Sensor eine Spalte durch PHP-Skript anlegen müssen wenn ich die in der Software anlege. ... Wenn ich den Sensor in der Software lösche werde ich die Spalte löschen.

In der DB? Ja nicht! Das ist der allerfalscheste Weg! Siehe Normalisierung: http://www.sqldocu.com/nine/normalform1.htm

Datenhaltung bitte nicht mit Ausgabe verwechseln. Eine DB ist KEIN Excel!

[hruendel]

In der DB? Ja nicht! Das ist der allerfalscheste Weg! Siehe Normalisierung: http://www.sqldocu.com/nine/normalform1.htm

Datenhaltung bitte nicht mit Ausgabe verwechseln. Eine DB ist KEIN Excel!

Kommt auf die Verwendung an. Wenn einer den Sensor aus dem System löscht wird über den Datenverlust gewarnt. Das macht man auch nicht jedes Mal. Das System ist dan halt auf die Menge der Sensoren flexibel. Da die Messwerte später gruppiert und per Mittelwert gerundet werden (z.B. nach Tag, Woche Monat) ist wohl eine Tabelle abgeschlossene Tabelle besser. Sonst kämpft man immer mit solchen komischen MySQL Anfragen.

[hausl]

Das System ist dan halt auf die Menge der Sensoren flexibel.

Noch flexibler und zusätzich korrekt im Sinne des Erfinders ist eine saubere Normalisierung. Gerade wenn du Auswerten willst, wirst du es dir damit schwer machen.

[Andreas]

Ich vermute, ich werde pro Sensor eine Spalte durch PHP-Skript anlegen müssen wenn ich die in der Software anlege.

Wie aktuell müssen die Daten denn sein? Sonst mach dir doch einfach eine Cache-Tabelle, die 2 mal am Tag aktualisiert wird und lade die Daten daraus... so hast du Performance UND Normalisierung