Im Wiki zu DbLog https://wiki.fhem.de/wiki/DbLog (https://wiki.fhem.de/wiki/DbLog) wird empfohlen, sowohl einen Primary Key als auch einen Index zu setzen.
create index idx_device_reading_timestamp on history (device, reading, timestamp);
- Zum Index:
- Wer eigentlich benutzt diesen Index?
- FHEM?
- Die Datenbank selbst?
- Ist die Schreibweise des Bezeichners idx_device_reading_timestamp wichtig?
- Meine vermutete Antwort ist, dass die Datenbank selbst diesen Index benutzt und seine Bezeichnung egal ist. ::)
ALTER TABLE `fhem`.`current`
[...]
ADD PRIMARY KEY (`DEVICE`, `READING`);
- Zum Primary Key:
- Ist er überhaupt notwendig?
So wie ich die Anleitung verstanden habe, ist sein einziger Zweck, Dopplungen zu vermeiden.
- Aber welche Dopplungen sind gemeint?
Die genannten gleichen Readings bei verschiedenen Geräten sollen eben gerade nicht entfernt werden.
- Warum ist er nur in der current-Tabelle und nicht auch in der history-Tabelle eingeführt?Wird die current 1:1 in die history kopiert, so dass dort keine explizite Definition notwendig ist?
- Ist nicht letztendlich der Primary Key ein dem Index gleichwertiges Konstrukt? Es werden doch beides Mal Attribute/Spalten zu "Adressen" zusammengefasst...
- Meine vermutete Antwort ist, da davon auch nichts in den Templates https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog) zu finden ist, dass der Primary Key nicht benötigt wird. ::)
Vielleicht gehöre ich mit meinem Thema in's Anfängerforum. Zumindest auf mein DB-Wissen trifft das Anfängersein zu...
Ich nehme gerne Antworten auf Dummy-Niveau entgegen. :-[
Vielen Dank und mit freundlichen Grüßen
Marius
Hallo Marius,
ZitatIm Wiki zu DbLog https://wiki.fhem.de/wiki/DbLog wird empfohlen, sowohl einen Primary Key als auch einen Index zu setzen.
Ich habe jetzt zwar nicht das ganze Wiki dazu gelesen, aber m.M. nach reicht es aus entweder den Index oder den Primary Key anzulegen. Aber es hat sich wahrscheinlich bisher noch niemand die Mühe gemacht einen Laufzeitvergleich zwischen den verschiedenen Varianten durchzuführen (ich auch nicht).
ZitatWer eigentlich benutzt diesen Index?
Der Index ist für die Datenbank ein "Telefonbuch" und ist für die schnelle Leseoperationen (SVG-Darstellung, DbRep-Auswertung,...) essentiell wichtig !
ZitatIst die Schreibweise des Bezeichners idx_device_reading_timestamp wichtig?
Nein.
ZitatZum Primary Key - Ist er überhaupt notwendig?
Nein, er ist nicht notwendig. Aber er ist sehr hilfreich um doppelte Datensätze zu verhindern.
Man kann den PK natürlich sowohl in der current als auch in der history Tabelle setzen. Allerdings muss er für die beiden Tabellen unterschiedlich aufgebaut sein.
für current:
ALTER TABLE 'current' ADD PRIMARY KEY (DEVICE, READING);
für history:
ALTER TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
Der PK verhindert immer doppelte Datensätze deren Werte bezüglich der im Index enthaltenen Felder identisch sind.
Für current braucht man nur Kombinationen aus Device/Reading die Unique sein sollen für die Auswahl bei SVG-Erstellung.
Der PK für die history muss auch das TIMESTAMP-Feld beinhalten, sonst würden aufeinander folgende Datensätze mit gleichen Werten für Device, Reading nicht geloggt werden.
Der Autor des Wiki-Beitrags hat das Beispiel für current erstellt, aber für history einen Hinweis geschrieben den man allerdings leicht überlesen kann.
ZitatWird die current 1:1 in die history kopiert, so dass dort keine explizite Definition notwendig ist?
Ganz falsch, gleich vergessen !!
ZitatIst nicht letztendlich der Primary Key ein dem Index gleichwertiges Konstrukt? Es werden doch beides Mal Attribute/Spalten zu "Adressen" zusammengefasst...
Nein ist nicht gleichwertig ! Ein PK verhindert mehrfache Datensätze wie oben beschrieben, ein Index tut dies nicht sondern ist "nur" ein "Inhaltsverzeichnis".
Für weitere Infos zum Datenbankthema empfehle ich dir diesen Thread:
https://forum.fhem.de/index.php/topic,65860.0.html
Grüße
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 02 November 2018, 21:38:55Der PK verhindert immer doppelte Datensätze deren Werte bezüglich der im Index enthaltenen Felder identisch sind.
OK, habe ich in meinem Hirn abgespeichert als "Möglichkeit auf DB-Ebene zu verhindern, dass doppelte Einträge auftreten". (Wo auch immer diese doppelten Einträge herkommen...)
Zitat von: DS_Starter am 02 November 2018, 21:38:55Für weitere Infos zum Datenbankthema empfehle ich dir diesen Thread:
https://forum.fhem.de/index.php/topic,65860.0.html
Danke für die Blumen; da bin ich noch meilenweit entfernt. Ich freue mich erst einmal, die Anbindung zum Laufen gebracht zu haben.
Vielen Dank für deine Unterstützung!