Post #5 erklärt doch eigentlich recht gut was combie meint. (zumindest so wie ich das verstehe)
Man speichert keine Daten in einer Datenbank, die vorberechnet sind, wenn die Datenbank das selbst machen kann.
Also anstatt nur die reinen Schaltzeiten mit dem entsprechenden Zeitpunkt / Zeitraum zu speichern und dann bei einer Abfrage diese Zeiten aufzusummieren, werden die Daten bereits aufsummiert gespeichert.
Damit ist es z.B. viel schwerer die Summe der Schaltzeiten für bestimmte Zeiträume direkt aus der Datenbank abzufragen, ohne mehrere Abfragen zu machen und dann unterschiedliche Werte gegeneinander aufzurechnen.
Wenn ich z.B. wissen will wie oft das Licht geschaltet wird im Vergleich zwischen Sommer- und Winterhalbjahr, oder ob zwischen 18:00 und 00:00 Uhr öfter geschaltet wird, als zwischen 00:00 und 04:00 Uhr.
Es kann durchaus Gründe geben gegen die o.g. Regel zu verstossen, allerdings werden die aus dem Postings nicht sichtbar.
Das Argument, das die Abfragen sonst langsam sind, muss aber in dem Fall erstmal belegt werden, wenn ein Hinweis das es keine so gute Idee ist Daten vorverarbeitet zu speichern damit entkräftet werden soll.
Denn eine Abfrage ist sicher dann langsam, wenn ich ein "select *" auf die DB mache und dann in meiner Software alle einzelnen Werte aufsummiere. Mache ich aber ein "select sum(schaltzeit)" addiert mir das die Datenbank (und mit einem guten Cache ist das sau schnell), dann ist die Abfrage plötzlich nicht mehr so langsam.
Das ist ein reines Beispiel zur Erklärung und soll dem TO nichts unterstellen. Allerdings ist ein Hinweis auf die 5 Normalformen einer Datenbank durchaus berechtigt, finde ich, wenn jemand eine DB mit Millionen Einträgen betreibt und noch nix davon gehört hat. Ein entsprechender Link der als Einstieg in die Materie dient wurde ja auch gleich mitgeliefert.
Mario.