[vz-dev] Fwd: Re: Offene Enden

Justin Otherguy justin at justinotherguy.org
Mon May 17 07:29:23 CEST 2010


Moin Jens,

Am 12.05.2010 um 00:56 schrieb Jens Wilmer:

> Hallo zusammen,
> 
> Am 06.05.2010 23:45, schrieb Justin Otherguy:
>> das kann ich aufklären: die UUID wird nicht pro Eintrag in der DB gespeichert; die UUID wird vorher (über eine separate Tabelle) in eine fortlaufende ID aufgelöst und dann mit abgespeichert. Das ist also kein Problem.
>> 
> Wenn das dann mehr als 256 Leute Nutzen, ist die ID vielleicht schon ein 
> signifikanter Teil der Datenmenge. Aber es geht ja nicht nur darum, 
> sondern auch um die Datenhaltung. Macht man eine Tabelle pro UUID und 
> Eingang, kann man den Zeitstempel als Clustered Index benutzen, damit 
> wird immer hinten an die Tabelle angehängt und man bekommt alle 
> benötigten Daten direkt am Stück aus der Tabelle geliefert. Die 
> Zusammenfassung in aller Daten in eine Tabelle bringt nur dann Vorteile, 
> wenn Daten aus mehreren Quellen zusammen abgefragt werden und dass auch 
> nur, wenn es gemeinsame Indizes gibt, die nicht mehr so viel Sinn 
> machen, da der Pflegeaufwand deutlich über dem Nutzen liegen dürfte. 
> Aber mit 5 Zählern und den Daten von 6 Monaten macht das keinen großen 
> Unterschied.
...das klingt interessant. Giess das doch mal in PHP - dann können wir's ja mal ausprobieren.

Ich glaube, wir sollten mehr coden und weniger diskutieren - am praktischen Beispiel klären sich manche Fragen sicher leichter.
Ich wäre auf die Idee mit 1 Tabelle/UUID nicht gekommen - das ist originell. Bei der Auswertung ist das sicher schneller, insbesondere bei einer grossen Anzahl UUIDs. Spannend ist natürlich die Frage, wie schnell das beim Loggen ist. Hinzu kommt, dass ist das Projekt momentan eher auf viele kleine dezentrale Implementierungen zusteuern sehe (mein.volkszaehler, "embedded volkszaehler"). Aber wie gesagt: wenn Du das in PHP-Form schickst, können wir's ja mal ausprobieren.

> Die Detektion von 70ms langen Impulsen ist eine Echtzeitfähigkeit, die 
> zum einen durch die Nutzung von Interrupts, zum anderen durch einen 
> Echtzeitkernel gelöst werden kann. Linux ist in dem Bereich nicht gerade 
> die effizienteste Wahl aber 50ms Reaktionszeit sind mit 
> Echtzeiterweiterungen kein Problem. Ich weiß nur nicht, ob das noch 
> unbedingt die geforderte Einfachheit bietet.
ACK. Das weiss ich auch nicht. Wenn wir das ausprobieren, erfahren wir's vielleicht ;-)

>> - eine Kombination aus ATmega+Emb. Linux halte ich nicht für sinnvoll; da stellt sich für mich die Frage nach der Zielgruppe; das wäre zwar sicher technisch eine spannende Lösung, macht den Aufbau aber nicht gerade einfacher
>> 
> Aber auch nicht schwerer. Man benötigt keine zusätzlichen Fähigkeiten zu 
> denen, die man auch braucht, um einen Edimax-Router entsprechende 
> Anzuzapfen oder ein Mini Embedded Linux Platinchen in Betrieb zu nehmen.
Einverstanden, schwerer wird's nicht, aber aufwändiger. Mit einer Lösung auf Basis von Flukso würde der Volkszähler für eine ganz andere Zielgruppe interessant.

>> - eine solche Kombination würde dem Flukso schon sehr ähneln
> Gute Designs setzen sich halt durch :o)
:-)


Gruss, J.



More information about the volkszaehler-dev mailing list