MoonWolf wrote:

> Michal Kleczek denied rebel lies:
>
>> A dlaczego tak?
>> To mi pachnie modelem EAV - nie lepiej dla kazdej "danej" oddzielna
>> relacje (tabele)?
>
> To też rozważamy (całość jest na etapie projektu, chociaż jak zwykle
> trzeba na szybko robić coś działającego).
>

To mozna zrobic rownie szybko.

>>> jeden rekord dotyczący danej, która nigdy się nie zmieniła). Dane
>>> będą różne - ale zawsze zdarzą się serie powtarzających się
>>> wartości.
>> To zalezy od wymagan funkcjonalnych.
>> Nie wiem dlaczego kolejne odczyty z urzadzen sa nieistotne jezeli ich
>> wartosc sie nie zmienila w stosunku do poprzedniego, ale sa istotne
>> jezeli sie zmienila.
>
> Bo wtedy można te wartości odtworzyć (poza bazą danych) mając daty
> zmian.

Mozna odtworzyc wartosci, ale nie mozna odtworzyc czasu odczytu. Rozumiem,
ze jest on nieistotny i istotny jest tylko moment, kiedy nastapila zmiana.

--
Michal

do góry

Michal Kleczek denied rebel lies:

>> To też rozważamy (całość jest na etapie projektu, chociaż jak zwykle
>> trzeba na szybko robić coś działającego).
> To mozna zrobic rownie szybko.

Ano można, być może tak zrobimy.

>> Bo wtedy można te wartości odtworzyć (poza bazą danych) mając daty
>> zmian.
> Mozna odtworzyc wartosci, ale nie mozna odtworzyc czasu odczytu.

I jak zauważył Krzysztof nie ma informacji o sytuacjach alarmowych.

> Rozumiem, ze jest on nieistotny i istotny jest tylko moment, kiedy
> nastapila zmiana.

W zasadzie tak - na pytanie w stylu "jaka była wartośc parametru A 12
lutego 2011r o 12:11:41" da się odpowiedzieć.

Wyszło na rok ponad 63mln rekordów na urządzenie (przy 20 parametrach).
Czy to dużo czy mało - to już pytanie na pl.comp.bazy-danych. A
obrobienie tego (np. do wykresu) - cóż, skoro da się zmniejszyć liczbę
danych obrabianych na raz (widoki), to nie powinien być problem nawet
dla skryptu PHP jak sądzę...

Chyba że RRD - ale pod warunkiem, że nie będzie trzeba odpowiadać na
pytania jak to powyżej.

--
<:> Roger, MoonWolf Out <:>|Let you run, then i pull your leash
(::) (::)|
(:) JID:m...@j...org(:)| http://karakkhaz.prv.pl

do góry

Daniel Podlejski denied rebel lies:

> SQL Antipatterns, Metadata Tribbles
> http://www.slideshare.net/billkarwin/sql-antipattern
s-strike-back
> slajdy 5 do 16

Dobre. To też rozważamy (:)

--
<:> Roger, MoonWolf Out <:>|Victims of fury are cowardly now
(::) (::)|
(:) JID:m...@j...org(:)| http://karakkhaz.prv.pl

do góry

>
> Baza danych będzie prosta - rekord z 'nazwą' danej, jej wartością i
> datą zapisania (każda dana to jeden rekord, danych będzie kilkanaście,
> zapis co 10sek 24h/7/365. Źródeł tych danych będzie więcej, dla każdego
> przewidziana jest osobna tabela, będzie tego nieokreślona liczba - na
> pewno będą przybywać).

Ja bym nie robil osobnej tabeli na kazda - mozesz wrzucic wszystko do
jednej wyrozniajac np. IDTypu + tabelka IDTypu, Nazwa
Mas jednolita obsluge KAZDEGO zrodla, bez wielkich kombinacji

>
> Pytanie jest takie: czy warto (a jeśli tak to w jakich okolicznościach)
> 'upakowywać' dane składowane w bazie - na takiej zasadzie, że jeśli
> dana się nie zmieniła to robimy update rekordu zmieniając datę na
> aktualną (czyli w skrajnym wypadku w bazie będzie jeden rekord
> dotyczący danej, która nigdy się nie zmieniła). Dane będą różne - ale
> zawsze zdarzą się serie powtarzających się wartości.

To zalezy co chcesz osiagnac. Jezeli chcesz miec pelne archiwum, czyli
jak sie cos w czasie zmienialo, to nie update, tylko insert kazdej
wartosci.


>
> Z danych tych będą sporządzane wykresy (raczej dla każdego źródła
> osobno - czyli zapytania w obrębie jednej tabeli) - tutaj właśnie
> powstała różnica zdań. Niektórzy boją się dużej liczby danych do
> obrobienia (po kilku latach) i długiego czasu generowania wykresu.
> Przeciwnicy twierdzą, że po to jest baza danych, żeby składować dane a
> takie kombinacje w kodzie aplikacji zniweczą oszczędności. I w ogóle
> pachnie to 'premature optimization'.

Ale co znaczy "dlugiego czasu"? 15 sek? czy 20 godzin?
Jezeli masz tak prosta baze to obojetnie ile tych danych bedzie, przy
sensowanie zalozonych indeksach i sensownym zapytaniu - czasy beda w
sekundach.

>
> Dodatkowe pytanie - czy język programowania lub silnik bazy danych może
> mieć wpływ na odpowiedź na to pytanie (celowo nie wspomniałem w czym to
> jest robione)?

Jezyk mniej, silnik na pewno. Plus - sposob generowania wykresow i
przygotowania danych.
Jezeli zrzucisz robote przygotowujaca dane do wykresu na serwer to
czas bedzie inny niz przegladniecie 3-4 milionow rekordow pozycja po
pozycji w aplikacji.

Za duzo mozliwosci, za malo informacji - takie teoretyzowanie :)
Generalnie - ja bym zrobil jedna tabele, wrzucal wszystko co dostane a
pozniej...proste/mniej proste selecty wyciagajace dane do wykresow.

Pozdrawiam
Bolo

do góry