Tutorial - Wetterdaten und Datenbanken - Teil 1 - Einleitung

Wetterdaten und Datenbanken 


Achtung: Neue und aktualisierte Versionen der Tutorials finden Sie hier:

http://www.pscl.ch


Einleitung


Datenbanken eignen sich für die Ablage von Wetterdaten besonders gut. Diese wurden entwickelt, um große Datenmengen zu verwalten. Vereinfacht kann man sich Datenbanken wie eine Tabelle aus zB. Excel vorstellen. Oft enthalten Datenbanken mehrere solcher Tabellen, welche zudem miteinander verknüpft sein können.


Einige Vorteile


  • Schneller Zugriff
  • Filter / Sortierung
  • Berechnungen wie sum/min/max/avg
  • Datumsfunktionen
  • geringer Platzbedarf
  • komfortable Verwaltung


Tabellen


Hier ein Beispiel einer Tabelle:


MySQL Tabellen Inhalt angezeigt von phpMyAdmin



Für jede Spalte muss mindestens ein Name und Typ angegeben werden. Gewisse Typen verlangen zusätzliche Parameter wie z.B die maximale Grösse/Länge.


MySQL Tabellen Struktur angezeigt von phpMyAdmin


Speicherbedarf 


Gehen wir von einem 5 Minuten Speicherinterval aus., dann sind das 288 Datenzeilen pro Tag. Das sind pro Monat bereits 8640 und im Jahr schon über 105'000. Gehen wir von ca. 15 Spalten aus, sind das über 1.5 Millionen Einzelwerte pro Jahr. (So eine Tabelle mit Wetterdaten, belegt bei mir ca. 6 MByte im Jahr.)

Diese Datenmengen aufzunehmen, sollte für MySQL aber kein Problem darstellen. Die Zugriffszeiten hängen aber von der Abfrage selbst, sowie der Leistungsfähigkeit und Auslastung des Servers ab. 


Verwaltung:


Als Graphische Oberfläche dient uns das Tool phpMyAdmin. Es ist bei den meisten Providern vorinstalliert und erlaubt das einfache Verwalten von MySQL. Ansonsten bedient man eine Datenbank mit sogenannten sql-Befehlen. Dazu aber Später mehr.




2 Kommentare:

  1. Ich würde vorschlagen, Temperatur, Feuchte und Druck als Integer zu speichern (jeweils mit 10 multipliziert). Das kann dann sogar eine kurze Integerzahl vom Typ SMALLINT sein. Diese belegt nur 2 Byte für einen Wert, während für die Dezimalzahl 5 Byte anfallen.

    Die dateid mit VARCHAR(16) belegt 17 Byte. Dabei reicht es eigentlich, datetime (8 Byte) zu haben. Daraus ergibt sich die dateid.

    Der Speicherbedarf für die Datenbank würde mit diesen Maßnahmen also von 40 Byte pro Datensatz auf 14 Byte sinken! Aus 10 MB pro Jahr würden dann nur noch 3,3 MB pro Jahr!

    AntwortenLöschen
  2. An Integer hab ich nicht gedacht. Besten Dank für diesen Kommentar.

    AntwortenLöschen