🚀 go-pugleaf

On Thursday, February 8, 2018 at 11:36:12 AM UTC-5, irq wrote:
> Przepraszam Cię za zaśmiecenie wątku poboczną dyskusją z poboczną osobą. Nie mogłem się opanować, ale osobie chyba właśnie o to chodzi.
> 
> W dniu poniedziałek, 5 lutego 2018 23:52:45 UTC+1 użytkownik baItiz napisał:
> > Będę zbierał dane z czujników typu temperatura wewnętrzna i zewnętrzna, 
> > wilgotność względna, ciśnienie powietrza. Lista nie jest zamknięta i 
> > mogą dojść kolejne np. strumień świetlny, stężenie pyłów w powietrzu.
> > 
> 
> Dlatego proponuję Ci abyś wyraźniej rozdzielił zadanie składowania zdarzeń od zadań raportowania. Do składowania przygotuj sobie jak najprostszą, być może partycjonowaną, tabelę pomiarów, zawierającą pary klucz-wartość, typu text - model EAV?. Będzie odporna na ewentualne przyszłe zmiany i na błędy, które wyczyścisz (i zdiagnozujesz) osobno. Nie zawracaj sobie tutaj głowy rozważaniami na temat typów danych, kluczowe jest aby tabela pomiarów zawierała po prostu to co dostaje z czujnika.
> 
> Mając tabelę pomiarów, a więc zabezpieczone stabilne składowanie danych pierwotnych (i ich backupowanie), możesz dowolnie projektować i modyfikować struktury przeznaczone do sprawnego raportowania, do których będziesz przepisywał odpowiednio zinterpretowane (i zagregowane?) wartości surowe. Tu będziesz mógł eksperymentować i doskonalić, nie ryzykując utraty stabilności rejestracji pomiarów.
> 
> Odnośnie identyfikacji miejsca pomiaru, ogranicz się w tabeli pomiarów do samego identyfikatora czujnika. Aby "zgeolokalizować" taki czujnik, zaprojektuj oddzielną tabelę czujników, w której będziesz prowadził ich ewidencję, a m.in. będziesz przechowywał ich lokalizacje oraz daty instalacji - wszak czujniki mogą się psuć, czy z innych powodów być wymieniane. Geolokalizację pomiaru uzyskasz przez odpowiednie złączenie (z tabelą pomiarów, bądź z tabelami raportującymi).

Zagadzam sie w 100% - w systemach rejestracji danych czasu rzeczywistego pewny zapis pomiaru jest najwazniesza rzecza - dlatego tabela powinna byc jak najprostasza. Reszte mozna dobudowac jak sie chce - w zaleznoci jak dane beda uzywane. Dodatkowo autor powinien oszacowac rozdzielczosc czasu w systemie i rozmiar strumienia danych (tzn jak szybko dane beda naplywaly i ile ich bedzie w danym momecie) - moze sie okazac ze sam SQL jest za wolny i trzeba dolozyc jakies posrednie buforowanie przed zapisem do bazy danych. W zasadzie w systemach rejestracji danych czasu rzeczywistego projektowanie bazy danych jest zadaniem drugorzednym - baza danych ma poprostu zapewnic pewna i trwala rejestracje pomiaru - jak dane sa pozniej uzywane/opisane nie jest to problemem systemu rejestracji.