Anpassen SQL-Adapter-Datenspeicherung

[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

Die Daten werden beim Anlegen der Datenpunkte übernommen

Ein Button im Adapter um die Punkte upzudaten.

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.

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

Alle Änderungen lassen sich über Views abwärtskompatibel gestalten.

[eric2905]

Moin,

@sissiwup:

Ich Würde die Tabelle datapoints ergänzen:

…

Die Daten werden beim Anlegen der Datenpunkte übernommen

Ein Button im Adapter um die Punkte upzudaten. `

die Idee ist gar nicht so schlecht, aber …

• Wenn Du diese Daten in die Datapoints packst, erzeugst Du sehr viele zusätzliche, redundante Daten.

• Der Update-Aufwand ist enorm, da Du nicht einfach mal ein Replace von "Schlafzimmer" zu "Wohnzimmer" machen kannst - plötzlich sind dann alle Deine Geräte im Wohnzimmer und das Schlafzimmer ist "leer"

• Gleiches gilt für Gewerk

• Beim Namen ist die Gefahr des zu viel Umbenennens zwar nicht so groß, bleibt aber bestehen. Und die Datenmenge sowieso

Ich würde diese Info an die Tabelle packen, wo der Datenpunkt zur ID gemachted wird.

Da sind die Daten einmalig und Änderungen sind einfach und eindeutig.

Gruß,

Eric

[sissiwup]

@eric2905:

Moin,

@sissiwup:

Ich Würde die Tabelle datapoints ergänzen:

…

Die Daten werden beim Anlegen der Datenpunkte übernommen

Ein Button im Adapter um die Punkte upzudaten. `

die Idee ist gar nicht so schlecht, aber …

• Wenn Du diese Daten in die Datapoints packst, erzeugst Du sehr viele zusätzliche, redundante Daten.

• Der Update-Aufwand ist enorm, da Du nicht einfach mal ein Replace von "Schlafzimmer" zu "Wohnzimmer" machen kannst - plötzlich sind dann alle Deine Geräte im Wohnzimmer und das Schlafzimmer ist "leer"

• Gleiches gilt für Gewerk

• Beim Namen ist die Gefahr des zu viel Umbenennens zwar nicht so groß, bleibt aber bestehen. Und die Datenmenge sowieso

Ich würde diese Info an die Tabelle packen, wo der Datenpunkt zur ID gemachted wird.

Da sind die Daten einmalig und Änderungen sind einfach und eindeutig.

Gruß,

Eric `

Hmmm.

datapoints ist genau diese Tabelle. Sie hat bei mir ca. 1600 Einträge, also alle Datenpunkte die ich logge.

+--------+------------+------+-----+-------------------+----------------+
| Field  | Type       | Null | Key | Default           | Extra          |
+--------+------------+------+-----+-------------------+----------------+
| id     | int(11)    | NO   | PRI | NULL              | auto_increment |
| name   | text       | YES  |     | NULL              |                |
| type   | int(11)    | YES  |     | NULL              |                |
| lname  | text       | YES  |     | NULL              |                |
| gewerk | text       | YES  |     | NULL              |                |
| raum   | text       | YES  |     | NULL              |                |
+--------+------------+------+-----+-------------------+----------------+

[apollon77]

@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 …