@sissiwup:
Ich Würde die Tabelle datapoints ergänzen:
lname = Vom Benutzer vergebener Name für den Datenpunkt
gewerk = Vom Benutzer vergebene Gewerke
raum = Vom Benutzer vergebene Räume
=> Vorteil: einfachere Verwendbarkeit der Datenpunkte für Auswertungen `
Namen sind vergleichsweise einfach, gewerke und räume aufwändiger rauszubekommen -vor allem bei Änderungen.
@sissiwup:
Die Daten werden beim Anlegen der Datenpunkte übernommen
Ein Button im Adapter um die Punkte upzudaten. `
Die "Objekte" werden eh vom Adapter bei Änderungen schon geholt, von daher ist das für den Namen ein guter Trigger.
Für Änderungen an Räumen und Gewerken müsste man noch mehr subscriben, aber auch machbar.
Würde das eher automatisch behandeln als auf knopfdruck.
@sissiwup:
Die Spalte ts (Timestamp) in den Tabellen ts_bool, ts_string, ts_number
aufteilen in ts und ms (ts*1000+ms) = alter ts.
Primary Key über beide Spalten.
=> Vorteil: ts ist jetzt im standard UNIX-TS-Format und damit einfacher auswertbar für Dashboards ungleich float. `
Das ist für mich echt fraglich … Da kann man wirklich ne einfache View bauen wenn man das wirklich braucht die "ts" umrechnet. Ansonsten ist es definitiv kein PK denke ich, aber das sind details.
@sissiwup:
Weitergehende Änderung:
ts_bool, ts_string, ts_number zusammenfassen zu einer Tabelle.
bool und number können in eine Spalte gespeichert werden, string bekommt eine eigene.
=> Vorteil: Einfachere Abfragen, simplere Fehlerbehebungen `
Hm, da kommt man jetzt in die Gefilde von gutem Datenbankdesign,. Normalisierung und sowas …
Aus reiner Abfragesicht ggf zu verstehen ... :-)
@sissiwup:
Alle Änderungen lassen sich über Views abwärtskompatibel gestalten. `
Grundsätzlich kann man über solche Ideen nachdenken.
Kannst mal gern ein Github Issue anlegen.
Es gibt nioch andere Themen wie Performance Isssues in einigen DBs wo Indizes fehlen und so. Über einen zweiten "Contributor" wäre ich froh, ansonsten kann ich für das Thema zeitlich nichts versprechen …
