Datenbankaufbau für Messwerte

[lfdshafaosidhf]

Hallo zusammen

Habe Grundkenntnisse im Bereich Datenbanken und SQL Querie. Nun überlege ich mir gerade wie ich am Besten soll die Datenbank aufbauen. Dieses Projekt ist aus reiner neugierde entstanden. Mich nimmt es wunder wie man dies bei grossen Applikationen löst.

Ich habe verschiedene Typen von Messeinrichtungen.

Auf dem Dach ist eine Wetterstation, welche Niederschlag, Feuchtigkeit, Temperatur der Luft misst.
Zum anderen habe ich mehrere Elektrozähler welcher Strom, Leistung und Energie messen.

Wie soll ich die Datenbank am Besten aufbauen?

Meine Idee wäre es eine Tabelle für die Messdaten der Wetterstation zu erstellen, in welche sämtliche Werte zyklisch gespeichert werden.

Eine andere Tabelle wären die Energiezähler. Auch hier werden sämtliche Daten wie Strom, Energie und Leistung und Zeitstempel in einer Tabelle gespiechert.
Und dann mithilfe eines Index die verschiedenen Zähler Nummeriert.

Ist dieses Vorgehen richtig?

Oder wäre es besser eine Tabelle mit allen Werten (sowohl Wetterstation und Elektrozähler zum erstellen)?

Wie macht Ihr das wenn Ihr eine zweite Wetterstation im Einsatz habt, welche noch weitere Werte als Wetterstation 1 herausgibt. Zum Beispiel kann diese noch die Windrichtung erkennen.

Macht Ihr hierfür eine neue Tabelle oder eine Tabelle mit einem Feld welche nur Wetterstation zwei benötigt?

Danke für euer Feedback.

Gruss

 

[dabadepdu]

Das sind schon die richtigen Fragen.

Nur eins von den Begrifflichkeiten her: Ein Index ist im Bereich relationaler Datenbanken keine fortlaufende Zahl, sondern eine Suchhilfe in unterschiedlicher Ausprägung.
Du meinst Schlüsselfelder, Keys, primär und sekundär, Primary Key, Secondary Key oder Foreign Key, also Fremdschlüssel. Die richtige Sprache ist sicher auch hilfreich, nicht nur zu Anfang.

Im Prinzip hilft es schon, gleiche oder ähnliche Typen auch in die gleiche Tabelle zu stecken. Vor allem dann, wenn es viele gemeinsame Darstellungen dieser Daten gibt, also Abfragen, Reports usw. die dann immer auf die gleiche Tabelle gehen, statt sich alles „irgendwo“ zusammen zu suchen.

Zusatzdaten können über eine zusätzliche Tabelle abgebildet werden. Alternativ kann man mit Dokument basierten Spaltentypen arbeiten, vor allem JSON. Es ist ganz anders im Umgang, aber mittlerweile in guten DB auch gut integriert und sehr mächtig und schnell. Also platt gesagt, alles was nicht in Schema F passt, kommt in eine „Reste“ Spalte vom Typ JSON.

Dazu und anderen Features kann ich nur Postgres empfehlen als DB!

Und eine weitere Sache, die für den Anfang vielleicht komplex wirkt oder unverständlich, aber in der Praxis viele Vorteile bietet, die gezielte Nutzung von Views.

Views sind beliebig komplexe Abfragen, die einen Namen bekommen und so wie eine Tabelle abgefragt werden können. Greift man grundsätzlich über Views zu, kann man dahinter leicht die Tabellen umbauen, aber über die Views weiter normal darauf zugreifen. Entscheidest Du Dich bspw. irgendwo für 2 Tabellen mit unterschiedlichen Sensortypen, kannst Du in einem View eine gemeinsame Sicht auf beide definieren.

Wenn das Ganze auf einem Kleinrechner (Raspberry, ..) laufen soll, macht es auch Sinn zu überlegen, wie detailiert man die Werte speichert. Pro Sekunde, Minute, Stunde usw.. Es gibt dann verschiedene Möglichkeiten, sofort zu aggregieren oder erst später für Auswertungen oder noch anders..
Vielleicht denkt man auch über Datentypen nach, je schmaler, desto besser, zumindest wenn Millionen von Datensätzen zu erwarten sind. Ordentliches Handling der Datumswerte usw.

Und nicht zuviel drüber nachdenken, es wird erfahrungsgemäß öfter Umbauten geben. Weil man etwas nicht bedacht hat oder weil man neue Sensortypen bekommt und die Ansprüche steigen. Dann lieber da Zeit investieren und die ursprüngliche Idee nicht verbiegen.