Hallo,
Ich will nacheinander mehrere Tabellen, die alle gleich aufgebaut sind, aus einer Datenbank abrufen und dann alle gleichermaßen verarbeiten. Ohne das ich die Namen der einzelnen Tabellen kenne und nur weiß das es maximal 20 Stück sein können. Weiß jemand wie das geht?
Ich hoffe das ich es verständlich erklärt habe.
Postgresql Tabellen
@Hypec: gleich aufgebaute Tabellen sollte es in einer Datenbank nicht geben. Das hört sich stark danach an, als ob Du variable Information in den Tabellennamen kodiert hättest.
Statt also mehrere gleiche Tabellen zu haben, erweitere eine Tabelle um eine Spalte.
Also, falls die Tabellen Umsatz_Amerika, Umsatz_Europa heißen, würde man eine Tabelle Umsatz machen, mit einer zusätzlichen Spalte "Kontinent".
Statt also mehrere gleiche Tabellen zu haben, erweitere eine Tabelle um eine Spalte.
Also, falls die Tabellen Umsatz_Amerika, Umsatz_Europa heißen, würde man eine Tabelle Umsatz machen, mit einer zusätzlichen Spalte "Kontinent".
Es sind mehrere Tabellen da ich darin Messdaten speichere und das ganze zu unterschiedlichen Zeiten beginnt also alle Tabellen unterschiedlich lang sind. Zudem das ganze über eine Weboberfläch mit flask und HTML erweiterbar bleiben soll. Und ich so ja jede Spalte Abfragen müsste und dann auch noch zuordnen können.
Es klingt als ob in einem Fall einfach eine JSONB Spalte sehr hilfreich wäre: https://www.postgresql.org/docs/current ... -json.html
Mein Ziel ist es das ich heute eine Messstation aufstelle die Daten in die Datenbank überträgt. Dann zum Beispiel in einem Monat will ich eine 2. einfach über die Weboberfläche, wo mir auch die Messdaten angezeigt werden, hinzufügen können. Das soll dann am besten so funktionieren das ich nicht jedes mal was im Code verändern muss.
Dann benutz das richtige Design für die Tabellen.
Die Tabellen anhand von willkürlichen Punkten (in diesem Fall Zeitpunkten) zu zerteilen, ist falsch. Ich sehe auch nicht, wo das einen Vorteil bringen kann. Was willst du damit erreichen?
Google mal nach "Normalisierung" von Datenbanken, damit du ein Gefühl dafür bekommst, wie relationale Datenbanken von der Struktur her aufgebaut werden können.
Ich glaube, du hast noch nicht erwähnt, um was für Messdaten es geht. Angenommen es wären Wetterdaten, dann könntest das Design der Tabellen wie folgt aussehen:
Tabelle Werttyp -> id, Name
(Zum Beispiel 1, Temperatur)
Tabelle Messstation - > id, Name (ggf. weitere Daten wie Ort)
Tabelle Messung -> id, messstation_id, werttyp_id, Zeitpunkt, Wert
Und schon bist du flexibel in der Anzahl bon Stationen und der Arten von Werten, die du einfügen kannst.
Die Tabellen anhand von willkürlichen Punkten (in diesem Fall Zeitpunkten) zu zerteilen, ist falsch. Ich sehe auch nicht, wo das einen Vorteil bringen kann. Was willst du damit erreichen?
Google mal nach "Normalisierung" von Datenbanken, damit du ein Gefühl dafür bekommst, wie relationale Datenbanken von der Struktur her aufgebaut werden können.
Ich glaube, du hast noch nicht erwähnt, um was für Messdaten es geht. Angenommen es wären Wetterdaten, dann könntest das Design der Tabellen wie folgt aussehen:
Tabelle Werttyp -> id, Name
(Zum Beispiel 1, Temperatur)
Tabelle Messstation - > id, Name (ggf. weitere Daten wie Ort)
Tabelle Messung -> id, messstation_id, werttyp_id, Zeitpunkt, Wert
Und schon bist du flexibel in der Anzahl bon Stationen und der Arten von Werten, die du einfügen kannst.
Tabellen sind aber doch keine Bücherseiten, wo du jeden Tag eine neue beginnst. So liest sich das zumindest bei dir.
Du solltest für die Messdaten eine große Tabelle haben, wo alles drin steht. Mit einer Spalte für den Startzeitpunkt, eine für das Ende und eine oder mehrere für die eigentlichen Daten.
Wenn du dann die Daten von Freitag vor 2 Wochen brauchst, dann hol sie dir aus dieser großen Tabelle per SQL-Abfrage. Auch Gruppierungen nach Tag, Woche oder Monat werden normalerweise über SQL-Abfragen auf Basis des runtergeschriebenen Datenbestandes geregelt. Das Stichwort hierzu lautet "Reporting", falls du weitere Infos dazu haben willst.
Das löst man über die Einführung einer zusätzlichen Tabelle (z.B. STATIONS), wie mein Vorposter es schon erklärt hat. Einfach eine Zeile für die ID und eine für die Bezeichnung der Station oder ggf weitere Spalten für weitere Details.
Das Hinzufügen einer Station bildet man dann einfach über das Hinzufügen einer neuen Zeile in der zusätzlichen Tabelle ab. Die wird vom Backend der Web-Oberfläche auf Wunsch angelegt. Immer wenn dann Messergebnisse in die Tabelle für alle Messdaten geschrieben werden, muss man halt die ID der Station mit angeben.
Also es sind Wetterdaten die ich habe und das ganze ist momentan so aufgebaut.
Danke für die vielen Tipps ich lese mir das alles jetzt mal durch.
Code: Alles auswählen
zeit ,luftfeuchtigkeitinnen, temperaturinnen, luftfeuchtigkeitausen, temperaturausen, erdfeuchtigkeit, luxOkay, dass es für Zeitangaben ein eigenes Datenformat gibt (also kein Text) hast du beachtet bzw angewendet? Das ist wichtig für die späteren Abfragen.
Und wie gesagt: Für mehrere Stationen solltest du eine passende station_id als weitere Spalte einführen. Die würde ich wahrscheinlich direkt hinter den Zeitpunkt einfügen.
Und wie gesagt: Für mehrere Stationen solltest du eine passende station_id als weitere Spalte einführen. Die würde ich wahrscheinlich direkt hinter den Zeitpunkt einfügen.
Nein das hab ich momentan noch nicht beachtet aber das ist ein guter Tipp. Momentan frag ich meine Daten mit einer dieser 2 Zeilen ab und der Timestamp ist als Text in der Tabelle.
Wie findet ihr das Layout oder gibt es noch Verbesserungsvorschläge. Wusste nicht wie ich das hier besser zeigen kann als in einer Csv Tabelle.
Datum
ID,Jahr,Monat,Tag,Stunde,Minute
1111,2019,3,16,12,0
1112,2019,3,16,13,0
1113,2019,3,16,14,0
1114,2019-03-16 15:00
Welches Datumsformat ist besser das bei ID 1111-1113 oder das bei ID 1114?
ID,STATION_ID,luftfeuchtigkeitinnen,temperaturinnen,luftfeuchtigkeitausen,temperaturausen,erdfeuchtigkeit,lux
1111,1,76.10,23.60,53.90,22.30,606,0.11
1111,2,76.10,23.60,53.90,22.30,606,0.11
1111,3,76.10,23.60,53.90,22.30,606,0.11
1112,1,76.10,23.60,53.90,22.30,606,0.11
1112,2,76.10,23.60,53.90,22.30,606,0.11
1112,3,76.10,23.60,53.90,22.30,606,0.11
1113,1,76.10,23.60,53.90,22.30,606,0.11
1113,2,76.10,23.60,53.90,22.30,606,0.11
1113,3,76.10,23.60,53.90,22.30,606,0.11
Die Werte sind später natürlich nicht alle gleich die hab ich nur kopiert um die Tabelle aufzufüllen. Würdet ihr die Tabelle so anlegen oder für jede Station dann nochmal eine eigene?
Code: Alles auswählen
cur.execute("SELECT TIMESTAMP, LUFTFEUCHTIGKEITDRIN, TEMPERATURDRIN, LUFTFEUCHTIGKEITAUSEN, TEMPERATURAUSEN, ERDFEUCHTIGKEIT, LUX from MESSDATEN ORDER BY timestamp DESC LIMIT %s;", [ask_length])
Code: Alles auswählen
cur.execute("SELECT TIMESTAMP, LUFTFEUCHTIGKEITDRIN, TEMPERATURDRIN, LUFTFEUCHTIGKEITAUSEN, TEMPERATURAUSEN, ERDFEUCHTIGKEIT, LUX from MESSDATEN WHERE TIMESTAMP BETWEEN %s AND %s ORDER BY timestamp DESC;", (start, end))Datum
ID,Jahr,Monat,Tag,Stunde,Minute
1111,2019,3,16,12,0
1112,2019,3,16,13,0
1113,2019,3,16,14,0
1114,2019-03-16 15:00
Welches Datumsformat ist besser das bei ID 1111-1113 oder das bei ID 1114?
ID,STATION_ID,luftfeuchtigkeitinnen,temperaturinnen,luftfeuchtigkeitausen,temperaturausen,erdfeuchtigkeit,lux
1111,1,76.10,23.60,53.90,22.30,606,0.11
1111,2,76.10,23.60,53.90,22.30,606,0.11
1111,3,76.10,23.60,53.90,22.30,606,0.11
1112,1,76.10,23.60,53.90,22.30,606,0.11
1112,2,76.10,23.60,53.90,22.30,606,0.11
1112,3,76.10,23.60,53.90,22.30,606,0.11
1113,1,76.10,23.60,53.90,22.30,606,0.11
1113,2,76.10,23.60,53.90,22.30,606,0.11
1113,3,76.10,23.60,53.90,22.30,606,0.11
Die Werte sind später natürlich nicht alle gleich die hab ich nur kopiert um die Tabelle aufzufüllen. Würdet ihr die Tabelle so anlegen oder für jede Station dann nochmal eine eigene?
Es war eigentlich so gemeint, dass du einen von den vorhandenen SQL-Typen für die Zeitangabe nehmen sollst. In deinem Fall bietet sich DATETIME an. Von selbst erfinden war eher nicht die Rede.
Vielleicht befasst du dich erstmal ausgiebiger mit den Grundlagen von SQL. Dann fällt es leichter, über die gleichen Dinge zu sprechen. Schau dir außerdem mal SQLAlchemy an. Damit wird die Überführung von Python-Objekten in SQL-Datenbanken deutlich vereinfacht, da man es nicht mehr direkt mit den SQL-Statements zu tun hat.
Auch stellt sich die Frage, ob du wirklich eine Datenbank für deine Anforderungen benötigst. Das was du bisher machst, lässt sich auch leicht mit JSON abbilden. Dafür hat Python auch das passende Modul an Board: https://docs.python.org/3/library/json.html
Vielleicht befasst du dich erstmal ausgiebiger mit den Grundlagen von SQL. Dann fällt es leichter, über die gleichen Dinge zu sprechen. Schau dir außerdem mal SQLAlchemy an. Damit wird die Überführung von Python-Objekten in SQL-Datenbanken deutlich vereinfacht, da man es nicht mehr direkt mit den SQL-Statements zu tun hat.
Auch stellt sich die Frage, ob du wirklich eine Datenbank für deine Anforderungen benötigst. Das was du bisher machst, lässt sich auch leicht mit JSON abbilden. Dafür hat Python auch das passende Modul an Board: https://docs.python.org/3/library/json.html
@snfau: JSON zu empfehlen für eine Aufgabe, in der ein beständiger Strom von Daten angehangen werden soll halte ich für falsch. JSON - wie XML, das früher populärer war - braucht schließende Klammern, die man also zum anhängen wieder öffnen und dann schließen muss. Das ist unglücklich und führt bei einer naiven Umsetzung dazu, dass immer alle Daten gelesen und geschrieben werden. Nicht so toll. da müsste es also schon JSON streaming sein, und das ist insbesondere für den TE bestimmt eine Herausforderung.
Die Datenbanken sind für solche Szenarien optimiert. Und reporting bekommt man noch kostenlos dazu.
Die Datenbanken sind für solche Szenarien optimiert. Und reporting bekommt man noch kostenlos dazu.
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.
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.
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.