Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[JoeALLb]

Wow, vielen Dank, das klingt großartig!!!
Werds heute Abend testen, wenn ich zuhause bin!

Diese Verfahren stellt m.M. nach sicher dass mathematisch nichts "verloren" geht. Vom logischen Standpunkt ist es natürlich nicht unbedingt schlüssig da der Verbrauch ja eher zwischen dem 02.11. und 30.11 anfiel. Vielleicht kriege ich das noch besser geregelt, mal schauen.

Ist denke ich schon ok, ersteres ist im Moment wichtiger als letzteres.... denn wenn mir das nicht gefällt, kann ich ja (zumindest einstweilen) mir selbst noch einen
Zwischen-Wert ausrechnen, der das Ergebnis dann besser "verteilt". Danke in diesem Zusammenhang auch für deine "insert" funktion!


Danke Heiko,
schöne Grüße Joe

[JoeALLb]

Hm, konnte es doch schon jetzt testen (erstaunlich, was manchmal am handy alles so klappt).

Ivh bekomme nun öfter Minuseinträge, so wie in diesem Beispiel.

Code: [Auswählen]

2012-07-01__stromverbrauch__2012-07 11400.9000
2016-12-10 13:49:33 2012-08-01__stromverbrauch__2012-01 -11400.9000
Ich wollte das jetzt nur melden, die genauen Daten dazu muss ich mir tatsächlich später ansehen, aber eigentlich sollte die DIFF-Funktion ja nie negativ werden, oder?

[DS_Starter]

Hi Joe,

aber eigentlich sollte die DIFF-Funktion ja nie negativ werden, oder?

nee, sollte nicht.

Wie gesagt ... erstmal testen und zusammentragen. Dann korrigieren wir wieder bis es richtig klappt.

Bis später ...
Grüße Heiko

[DS_Starter]

Hi Joe,

ich glaube das Problem mit den negativen Diffs in der V4.8.2 (Eingang) beseitigt zu haben.
Habe es mit deinen Wasserdaten vom letzten Mal durchlaufen lassen.
Klappt sogar wenn nur ein Wert im Monat vorhanden ist. Warnung kommt aber noch.

Aber jetzt muß ich echt ... bis später

Heiko

[JoeALLb]

Hallo Heiko,

meine Tests verliefen bisher sehr erfolgreich, vielen Dank für die Änderungen!
Mein Heizungszähler, der eigentlich recht häufig Werte liefert,  hat damit im letzten Jahr gleich 120KWh mehr angezeigt... das unterscheidet sich nur um 5 kwh von der
Ablesung, aber diese ist ja nicht am 31.12...
Ich werd das nochmals demnächst genau nachrechnen, aber ich gehe davon aus, dass dies jetzt stimmt.

[DS_Starter]

Morgen Joe,

das hört sich gut an ... danke für die Rückmeldung.
Ich werde auch noch Tests in verschiedenen Konstellationen durchführen und das Ganze auch mal noch mit SQLite durchziehen.

Dauert aber noch bisschen ...

Grüße
Heiko

[DerFrickler]

aus dem Wiki:

 

Code: [Auswählen]

ALTER TABLE 'fhem'.'history' ADD INDEX `Reading_Time_Idx` (`READING`, `TIMESTAMP`) USING BTREE;
 oder:
 CREATE INDEX Reading_Time_Idx ON `fhem`.`history` (READING, TIMESTAMP);
jetzt helft doch bitte mal einen Laien in Sachen DB weiter... worin liegt der Unterschied?

Gruß!

[DS_Starter]

Hallo,

macht faktisch keinen Unterschied außer in der obligatorischen Angabe eines Indexnamens ....

Zitat aus  http://stackoverflow.com/questions/17113149/what-is-the-difference-between-mysqls-create-index-and-alter-add-index  ->
What is the difference between MySQL's create index and alter add index?

The implementation is the same on the server-side.

The only practical difference is that with ALTER TABLE, you have the option to create an index without specifying a name for the index. The server generates a default name, as the name of the first column in the index, with a number suffix if necessary.

Whereas with CREATE INDEX syntax, you must specify a name for the index.

[DerFrickler]

wenn ich mit folgenden Anweisungen eine DB erstelle:

sudo sqlite3 /opt/fhem/DbLog.db

CREATE TABLE 'history' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE 'current' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));

wie müsste dann die Anweisung für den INDEX aussehen?

edit:
CREATE INDEX Reading_Time_Idx ON 'history' (READING, TIMESTAMP);

[DS_Starter]

Es kommt darauf an welche Felder der Index einschließen soll. Das hängt davon ab wie letztendlich die Abfrage der DB erfolgen soll.

Mein Beispiel:

Code: [Auswählen]

CREATE INDEX Reading_Time_Idx ON `history` (READING, TIMESTAMP);
fügt nur die Felder READING und TIMESTAMP zu diesem Index hinzu. Dieser Index würde Abfragen der Form " Select  .... where Reading = .... AND TIMESTAMP = ..." beschleunigen.  Man könnte nun noch weitere und im Extremfall alle Felder der DB mit hinzufügen.

Um zum Beispiel Device noch mit hinzuzunehmen würde es etwa so aussehen:

Code: [Auswählen]

CREATE INDEX Reading_Dev_Time_Idx ON `history` (READING, DEVICE, TIMESTAMP);
Entspechendes für die Tabelle "current" :

Code: [Auswählen]

CREATE INDEX Reading_Dev_Time_Idx ON `current` (READING, DEVICE, TIMESTAMP);
Problem dabei ist dass diese Indizes Platz auf der DB benötigen der u.U. an die Größe der Daten selbst herankommen.
Ich weiß jetzt nicht was der Hintergrund deiner Frage ist, aber ich würde den Erfolg (Verringerung Laufzeit) des Indexaufbaus einfach austesten und wegen des benötigten Platzes nur Indizes erstellen die einen Performancegewinn verursachen.

[DerFrickler]

Danke erst mal für Deine Antworten.

Im Grunde überlege ich mir gerade wie ich meine DB für Logdaten am besten aufsetzte und später auch Pflege. Im Wiki zu DbRep bin ich auf den Hinweis gestossen dass aus Performancegründen ein Index erstellt werden soll. Wenn ich die DB erneut aufsetze, dann aber auch von Anfang an richtig.

Gruß!

[DS_Starter]

Auf MySQL kannst/willst du nicht wechseln ?
Wenn ich wählen könnte (hab ich ja) würde ich auf MySQL setzen.

Während ich mit DbRep im Entwicklungsprozess mit beiden DB-Typen teste, komme ich immer wieder zu dem Ergebnis dass MySQL performanter arbeitet.
Möglicherweise ist das auch von meiner konkreten Testumgebung abhängig, doch ist dies mein Erfahrungswert. 

[DerFrickler]

Gab es bei MySQL nicht die Einschränkung in der Länge der Device Namen?

Gruß!

[DS_Starter]

Ja, die gibt es. Aber es etwas entspannt weil die Länge auf 64 Zeichen im DbLog abgeändert wurde.
Da!mit kommt man gut klar denke ich.

[JoeALLb]

Ja, die gibt es. Aber es etwas entspannt weil die Länge auf 64 Zeichen im DbLog abgeändert wurde.

Und zur Not kann man die Spaltenbreite selbst bei den Tabellen noch weiter erhöhen, funktioniert bei mir bisher recht gut.
Ich habe sogar auf einem kleinen Raspi v1 eine Mysql-DB am laufen, und es klappt wunderbar.
Natürlich ist die CPU-Auslastung etwas höher als bei SQLIte, dafür ist sonst vieles um vieles angenehmer.
zB gleichzeitiger Zugriff auf die DB von fhem und vom Anwender, auswertungen, stored Procedures, ..

Ich würde hier immer wieder mysql (oder aktueller MariaDB als 1:1 Ersatz für MySQL) verwenden.

@Heiko: Bei mir läuft die VErsion gut, und da sie für mich entscheidendes verbessert, würde ich für ein Eincheckem plädieren ;-)

sG
Joe