immer nur 7 tabellen

[ice polar]

Hallo, bin zwar neu hier aber was ich da lese ist schon abenteuerlich...

Es wurde bereits geschrieben, dass es da genau 1 Tabelle ("Messwerte") braucht mehr nicht. Diese eine Tabelle hat ein paar Spalten, z.B. "Datum", "Temp", "Light" und "Water" und ganz wichtig: Jede Spalte hat den korrekten Datentyp, also [datetime] für "Datum" und z.B. [integer] für die anderen Spalten -> damit wird meistens massiv Speicherplatz eingespaart!

Ein bisschen Pseudocode:

Code: Alles auswählen

CREATE TABLE MESSWERTE("Datum" datetime, "Temp" int, "Light" int, "Water" int)
CREATE UNIQUE INDEX IX_Datum FOR "Datum" ON MESSWERTE

Es kommt ja auch niemand auf die Idee für jeden Tag eine neue Datenbank anlegen zu wollen... Es ist eben so: 1 Datenbank und 1 Tabelle genügen vollauf, ein Index auf dem Datum wurde auch bereits erwähnt und damit ist das Thema Datenbank komplett abgeschlossen, da gibt es nichts mehr daran zu pfriemeln.

Alles andere kann dann die "Applikation" erledigen und zwar "straight forward" mit einer Datenbank und 1 Tabelle und den klar definierten Spalten in der Tabelle. Dafür gibt es in diesem Beispiel eigentlich genau 2 Befehle, nähmlich INSERT und SELECT.

INSERT schreibt die Daten in die Tabelle, immer schön alle 4 Werte "Datum", "Temp", "Light" und "Water". Fertig, da gibts nichts was kompliziert ist mit einer Datenbank (ausser man macht es sich so konsequent kompliziert wie in diesem Thread).

Code: Alles auswählen

INSERT MESSWERTE( "Datum", "Temp", "Light", "Water")
VALUES("Datum", "Temp", "Light", "Water")

Ist "Datum" ein Datentyp [datetime], so werden darin nebst dem Datum auch die Zeit (ziemlich genau sogar) abgespeichert, so dass es auch bei einem eindeutigen Index nie zu einem Schreibfehler (wie z.B. Duplikate Key) kommt. Es ist auch völlig Wurst, ob die Applikation die Messwerte alle 2 Stunden jede Minute oder jede Sekunde (oder unregelmässig) in die Datenbank schreibt, die Datenbank speichert die Werte einfach schnell und unkompliziert: So soll's sein.

SELECT braucht man, um die Daten für den erwähnten Plot wieder auszulesen. Python ist mächtig genug jeweils vom aktuellen Tagesdatum aus 7 Tage zurückzurechnen um so die Messewerte der vergangenen 7 Tage aus der Datenbank zu bekommen:

Code: Alles auswählen

SELECT "Datum", "Temp", "Light", "Water" FROM MESSWERTE WHERE "Datum" >= (Tagesdatum - 7 Tage)

Sollte es einmal nötig sein, ältere Daten zu löschen (z.B. alles was älter als 1 Jahr ist), so geht das mit diesem Datenmmodell ebenfalls auf einer einzigen Zeile:

Code: Alles auswählen

DELETE MESSWERTE WHERE "Datum" <= (Tagesdatum - 365Tage)

Es ist also offensichtlich, dass für das Vorhaben im Zusammenhang mit einer Datenbank keine besondere Magie notwendig ist, sondern einfach ein paar komplett unspektakuläre SQL-Befehle, nachdem die Datenbank und die Tabelle einmal(!) angelegt worden sind.

Es ist mir rätselhaft mit welchen Vorurteilen gewisse Programmierer einer Datenbank begegnen und eigentlich würde sich ja dafür auch SQLite3 eignen, ausser der "RASPI" hängt im LAN und man möchte die Messwerte vom PC aus übers Netzwerk aus der MySQL-Datenbank auslesen...

Viel Spass mit dem Vorhaben und wenn mit den gezeigten SQL-Befehlen noch etwas nicht verständlich ist, gebe ich gerne Auskunft.

Ice

PS: Ein anderes Datenmodell müsste zuerst ausführlichst begründet werden

[BlackJack]

Wäre das einfügen eines künstlichen Primärschlüssels schon ein anderes Datenmodell? Falls ja, hier die ausführliche Begründung: `sqlalchemy.orm`. SCNR.

[ice polar]

@BlackJack: Streng genommen schon. Ein "künstlicher" Primärschlüssel besagt bereits, dass dies etwas zusätzliches eben künstliches ist unter der Annahme, dass wir bereits einen guten Primärschlüssel haben, nähmlich das "Datum" mit dem Datentyp datetime wo die Zeit bis auf die Tausenstelsekunde mit dabei ist.
Die ausführliche Begründung kann durchaus in einer Beschränkung des ORM sein, wobei ich SQLAlchemy nicht als diesbezüglich beschränkt wahrnehme:

In SQLAlchemy, primary and foreign keys are represented as sets of columns; truly composite behavior is implemented from the ground up. The ORM has industrial strength support for meaningful (non-surrogate) primary keys, including mutability and compatibility with ON UPDATE CASCADE, as well as explicit support for other common composite PK patterns such as "association" objects (many-to-many relationships with extra meaning attached to each association).

Mein Grundsatz lautet: Keep it simple and stupid! kompliziert wird es von alleine...

[janb14]

Ersteinmal vielen Dank für all die tollen/langen Tutorials und Hilfestellungen.Ich bin mir bewusst das ich am Anfang viel falsch gemacht habe ...aber hey ich stehe halt auf die Methode "lerning by doing".Als Ergänzung vllt. noch ich habe jetzt auf vielerlei Anrat eine DB mit einem Table erstellt und es funktioniert .Dafür erstmal ein DICKES DANKE.Anbei sende ich euch die ersten Bilder meiner Projektseite.Nun wird erstmal noch ein bisschen an den Feinheiten gefeilt z.B. den Phplot graphen spiegeln .Bis dahin DANKE und PEACE