Korrekturvorschlag für db_create_mysql.sql

[tupol]

Hallo DBLog Autor,

die Vorlage zur Erzeugung der mysql Datenbank "db_create_mysql.sql" enthält eine zu kurze Länge für das Feld "Value". Das Modul KS300 erzeugt z.B. ein "state", das größer als 32 Zeichen ist. Ich schlage vor, das auf 50 zu ändern.

Code Auswählen Erweitern

CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(50), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(50), UNIT varchar(32));


gruß

tupol

[betateilchen]

Es macht an sich keinen Sinn, einen so langen state überhaupt zu loggen, da man zum Plotten in so einem Fall ohnehin lieber auf die Einzelreadings zurückgreifen wird, wodurch das gplot File sehr viel übersichtlicher wird.

[tupol]

Das Loggen dieser zusammenfassenden Readings hat zwei Gründe:
1. Weniger Speicherplatz und evt. auch weniger DB-Last für den Plot. (falls die regexp nicht von der DB berechnet werden.)
2. Es gibt keine Einzelreadings, weil sonst aus 10 Readings plötzlich 100 würden und der Modulautor das nicht wollte.

Ich habe etwa eine Stunde gebraucht, bis ich auf die Idee kam, das nicht meine regexp falsch war sondern aus der DB nur der halbe String kam. regexp sind für viele Nutzer einfach zu schwierig und da ist es fatal, wenn noch eine andere Fehlerquelle hinzukommt.

Ich habe zudem der Wert auf 60 erhöht, da auch 50 bei der Auswertung von statistischen Jahres-Readings zu kurz sein kann.

[betateilchen]

Dann ist aber Deine Festlegung auf 50 Zeichen genau so willkürlich wie das bisherige 32. Es gibt auch jetzt schon Module, die sehr viel längere Readings erzeugen. Eventuell ist CHAR generell der falsche Datentyp.

[tupol]

Stimmt. Vielleicht wäre es am besten, irgendwo in der Beschreibung oder in der Datei zu erwähnen, dass dieser Wert Grenzen setzt und eventuell angepaßt werden muss.

[Zephyr]

Wenn ich vielleicht noch zusätzlich anregen dürfte, den beiden Tabellen einen vernünftigen künstlichen Primärschlüssel zu spendieren...
In der jetzigen Form ist es unnötig schwer, Einträge aus der DB direkt anzusprechen...