Das da oben soll keine neu Erfindung sein sondern die Namen stehen nur der verständlichkeitshalber oben drüber. Das ich die Spalte dann als DATETIME definieren soll ist mir bewusst.
Das mit SQLAlchemy ist eine gute Idee über die ich mich genauer Informieren werde.
Ich glaube das JSON eine nicht so gute Idee ist, da bei einer Stündlichen Messung mit 6 Messwerten und bei mehreren Messstationen eine ziemliche Datenmenge zusammenkommt.
Postgresql Tabellen
Nein, das ist keine ziemlich Datenmenge. 10 Messtationen mit 6 Messwerten/h die einen Datensatz mit großzügigen 200 Byte erzeugen - da kannst du auf einer 8GB SD-Karte 76 Jahre lang aufzeichnen. Und deine Datenbank benutzt nicht magisch weniger Platz als JSON.
@Hypec: Mein Hinweis auf JSON bezog sich auf die relativ simple Struktur, die du vorliegen hast. Den Aspekt des Streamings hatte ich dabei nicht beachtet. Dafür ist JSON tatsächlich keine gute Wahl.
Ansonsten wären noch NoSQL-Datenbanken (Redis, MongoDB, ...) eine Alternative. Da gibt es dann keine Tabellen, sondern andere Ansätze zur Abbildung deiner Datenstrukturen. Die werden je nach System z.B. als Hashes oder Schemas bezeichnet und sind eher auf Objektorientierung ausgerichtet.
Mittels SQLAlchemy erhälst du das allerdings genau so, da dir die Tabellen quasi als Objekte übersetzt werden. Damit machst du also nichts verkehrt. Sobald mehrere Tabellen ins Spiel kommen, solltest du auf jeden Fall das Konzept von sogenannten Fremdschlüsseln verstanden haben, damit du die Tabellen sinnvoll miteinander verknüpfen kannst. Auch SQLAlchemy setzt dies letztlich voraus.
Ansonsten wären noch NoSQL-Datenbanken (Redis, MongoDB, ...) eine Alternative. Da gibt es dann keine Tabellen, sondern andere Ansätze zur Abbildung deiner Datenstrukturen. Die werden je nach System z.B. als Hashes oder Schemas bezeichnet und sind eher auf Objektorientierung ausgerichtet.
Mittels SQLAlchemy erhälst du das allerdings genau so, da dir die Tabellen quasi als Objekte übersetzt werden. Damit machst du also nichts verkehrt. Sobald mehrere Tabellen ins Spiel kommen, solltest du auf jeden Fall das Konzept von sogenannten Fremdschlüsseln verstanden haben, damit du die Tabellen sinnvoll miteinander verknüpfen kannst. Auch SQLAlchemy setzt dies letztlich voraus.
-
noisefloor
- User
- Beiträge: 3853
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
@__deets__:
Für zeitbasierte Daten könnte man noch InfluxDB in den Raum werfen. Wobei die Anforderungen sicherlich auch problemlos mit PostgreSQL abbildbar sind.
Gruß, noisefloor
@__deets__:
Redis kennt doch zwei Arten der Datenpersistenz.Redis ist normalerweise nur in-memory,
Für zeitbasierte Daten könnte man noch InfluxDB in den Raum werfen. Wobei die Anforderungen sicherlich auch problemlos mit PostgreSQL abbildbar sind.
Gruß, noisefloor
Das berührt nicht meine Antwort. WIE geschrieben wird, ist erstmal unerheblich. Es muss nur der gesamte KV Raum in den Speicher passen. Damit halt schnell nachgeschlagen werden kann. Anders als bei Postgres (oder auch afaik MongoDB), wo ggf halt nachgeladen wird.
Das zumindest ist mir so ergangen vor 3 Jahren oder so, und einen Weg das zu ändern abs damals nicht.
Das zumindest ist mir so ergangen vor 3 Jahren oder so, und einen Weg das zu ändern abs damals nicht.
Nochmal geschaut: sowas geht https://redis.io/topics/lru-cache
Eine wirklich geeignete DB ist das aber denke ich trotzdem nicht. Redis ist gut im Speicher. Nicht in zb Indizes über Zeitstempel, so das man die Frage nach “Temperatur von bis” gut beantworten kann.
Eine wirklich geeignete DB ist das aber denke ich trotzdem nicht. Redis ist gut im Speicher. Nicht in zb Indizes über Zeitstempel, so das man die Frage nach “Temperatur von bis” gut beantworten kann.
Flexible Abfragen sind halt immer noch am besten bei einer SQL-Datenbank möglich. Sofern man weiß, dass man nur eine ganz bestimmte Abfrage machen möchte, lassen sich die Daten im Falle von NoSQL vorab entsprechend strukturieren. Spielt hier aber alles keine Rolle, da ja laut TE nur PostgreSQL verwendet werden kann.
Ich denke übrigens, dass man sich über Performance oder Speicherverbrauch bei dieser relativ kleinen Datenmenge keine großartigen Gedanken machen muss. Klar wächst die Menge zunehmend, aber den RAM dürfte es so schnell nicht sprengen.
Ich denke übrigens, dass man sich über Performance oder Speicherverbrauch bei dieser relativ kleinen Datenmenge keine großartigen Gedanken machen muss. Klar wächst die Menge zunehmend, aber den RAM dürfte es so schnell nicht sprengen.
-
noisefloor
- User
- Beiträge: 3853
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
@__deets__ : das Redis hier nicht 1. Wahl ist sehe ich auch so.
Was bei so kleinen Datenmengen auch gehen würde: Daten in eine CSV-Datei schreiben und mittels Pandas auswerten.
Gruß, noisefloor
@__deets__ : das Redis hier nicht 1. Wahl ist sehe ich auch so.
Was bei so kleinen Datenmengen auch gehen würde: Daten in eine CSV-Datei schreiben und mittels Pandas auswerten.
Gruß, noisefloor
Was ich aber noch nicht verstanden habe bei der normalisierung von Datenbanken wie laufen die Tabellen neben einander? Also muss ich da dann immer 3 Tabellen abrufen um mir dann die Daten die ich haben will zusammen zubauen oder wie geht das ganze dann?
Das kommt auf die Art der Daten an und wie weit man ins Detail gehen möchte.
Eine Messstation bleibt wahrscheinlich längere Zeit bestehen und wird immer wieder referenziert. Hier könnte man im einfachsten Fall sich irgendein Kürzel oder Zahl als Kennung ausdenken. Eleganter wäre aber ein Eintrag in einer Extra-Tabelle mit automatisch angelegter ID, auf die man dann woanders Bezug nehmen kann. Dann lassen sich auch weitere Details wie Standort oder Aufstelldatum / Datum der Inbetriebnahme mit einpflegen.
Und eine weitere Tabelle braucht man dann für die eigentlichen Messungen. Was man da als Details eintragen kann, wurde ja schon besprochen. Jede Messung sollte natürlich auch wieder automatisch eine ID zugeteilt bekommen. Zum Beispiel können diese IDs benutzt werden, um zu dokumentieren, welche Messungen in welchem Monat / Woche / Tag durchgeführt wurden, ohne dass man jedes Mal die komplette Messung eintragen muss.
Das Prinzip lautet hier: Sparsamer Umgang mit Ressourcen (Speicher) durch Vermeidung von Redundanzen (Wiederholungen). Als weiterer Effekt werden damit Änderungen an den Daten an allen Stellen sichtbar, da überall auf den gleichen Datensatz verwiesen wird und nur dieser Datensatz angefasst wird. Die dazu passende Struktur und wieviele Tabellen du dafür anlegst, musst du dir schon passend zum Anwendungsfall selbst ermitteln.
Du musst halt, wie so oft bei der Programmierung, in Rollen denken: Eine Rolle ist die interne Datenhaltung, wo man IDs benutzt. Die andere Rolle ist die Aufbereitung für Anzeige beim Anwender. Dass dann mehrere Tabellen ins Spiel kommen, ist ganz normal.
Eine Messstation bleibt wahrscheinlich längere Zeit bestehen und wird immer wieder referenziert. Hier könnte man im einfachsten Fall sich irgendein Kürzel oder Zahl als Kennung ausdenken. Eleganter wäre aber ein Eintrag in einer Extra-Tabelle mit automatisch angelegter ID, auf die man dann woanders Bezug nehmen kann. Dann lassen sich auch weitere Details wie Standort oder Aufstelldatum / Datum der Inbetriebnahme mit einpflegen.
Und eine weitere Tabelle braucht man dann für die eigentlichen Messungen. Was man da als Details eintragen kann, wurde ja schon besprochen. Jede Messung sollte natürlich auch wieder automatisch eine ID zugeteilt bekommen. Zum Beispiel können diese IDs benutzt werden, um zu dokumentieren, welche Messungen in welchem Monat / Woche / Tag durchgeführt wurden, ohne dass man jedes Mal die komplette Messung eintragen muss.
Das Prinzip lautet hier: Sparsamer Umgang mit Ressourcen (Speicher) durch Vermeidung von Redundanzen (Wiederholungen). Als weiterer Effekt werden damit Änderungen an den Daten an allen Stellen sichtbar, da überall auf den gleichen Datensatz verwiesen wird und nur dieser Datensatz angefasst wird. Die dazu passende Struktur und wieviele Tabellen du dafür anlegst, musst du dir schon passend zum Anwendungsfall selbst ermitteln.
Na, das löst du halt beim Reporting auf. Der Leser interessiert sich ja weniger für die ID, sondern eher für den Namen oder Standort der Station. Das lässt sich dann passend einteilen, z.B. mittels GROUP BY.
Du musst halt, wie so oft bei der Programmierung, in Rollen denken: Eine Rolle ist die interne Datenhaltung, wo man IDs benutzt. Die andere Rolle ist die Aufbereitung für Anzeige beim Anwender. Dass dann mehrere Tabellen ins Spiel kommen, ist ganz normal.
Sorry das ich erst so spät antworte aber ich war mit anderen dingen beschäftigt. Ich habe jetzt meine Datenbank normalisiert. Mein Problem jetzt ist das ich momentan eine kostenlose Datenbank nütze die dafür allerdings auf 10.000 Reihen begrenzt ist. Wenn ich jetzt 3 Messstationen a 6 Werte habe sind das 432 Reihen am Tag und die Datenbank wäre nach 23 Tagen voll.
Was würde sich verändern wenn ich immer alle 6 Messwerte aus einer Messung in die selbe Reihe schreiben würde ?
Was würde sich verändern wenn ich immer alle 6 Messwerte aus einer Messung in die selbe Reihe schreiben würde ?
-
__blackjack__
- User
- Beiträge: 13068
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
Eine auf 10.000 Datensätze beschränkte Datenbank ist für vieles nicht brauchbar – insbesondere nicht für regelmässig anfallende Messdaten.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Mein Datenbank Design sieht momentan so aus:
WERTTYP: id, name
MESSSTATIONEN: id, name,owner
MESSUNG: id, messstation_id, werttyp_id, timestamp, wert
Meine Überlegung wäre es jetzt MESSUNG so umzuformen:
MESSUNG: id, messstation_id, timestamp, wert1, wert2, wert3, wert4, wert5, wert6
Ja das stimmt das wären dann aber immerhin mehr als 4 Monate die ich auf die Daten zurückgreifen könnte.
Ich weiß allerdings will ich solange ich das ganze noch Entwickel möglichst meine Kosten gering halten.
WERTTYP: id, name
MESSSTATIONEN: id, name,owner
MESSUNG: id, messstation_id, werttyp_id, timestamp, wert
Meine Überlegung wäre es jetzt MESSUNG so umzuformen:
MESSUNG: id, messstation_id, timestamp, wert1, wert2, wert3, wert4, wert5, wert6
Ja das stimmt das wären dann aber immerhin mehr als 4 Monate die ich auf die Daten zurückgreifen könnte.
Ich weiß allerdings will ich solange ich das ganze noch Entwickel möglichst meine Kosten gering halten.
Die Auswahl von DBMS ist gefühlt riesig. Wenn genau das System, das du einsezen willst, ein Feauture hat, das kein anderes bietet, dann musst du halt die Vollversion kaufen, damit es keine Beschränkung der Einträge in einer Tabelle gibt. Das Tabellendesign kaputtzufrickeln, nur damit es mit der Trial-Version läuft, wäre wenig zielführend.
Also: gibt es ein solches Feature? Falls nicht, setz halt ein, was es am Markt etabliert gibt: PostgreSQL, MariaDB/MySQL, sqlite3 wenn es lokal reich oder von mir aus auch so etwas wie Firebird.
Allerdings bin ich verwirrt: Das Thema heißt doch "Postgresql Tabellen" (sic!), da gibt es doch gar keine Beschränkung.
Also: gibt es ein solches Feature? Falls nicht, setz halt ein, was es am Markt etabliert gibt: PostgreSQL, MariaDB/MySQL, sqlite3 wenn es lokal reich oder von mir aus auch so etwas wie Firebird.
Allerdings bin ich verwirrt: Das Thema heißt doch "Postgresql Tabellen" (sic!), da gibt es doch gar keine Beschränkung.
-
__blackjack__
- User
- Beiträge: 13068
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@sparrow: Ich habe das jetzt so interpretiert das er eine kontenlose PostgreSQL bei einem Anbieter verwendet, der aber Geld sehen will wenn man da mehr als 10.000 Datensätze drin speichern möchte.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman