Mamy w firmie różnice zdań i chciałem się zorientować w pewnej kwestii.

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ć).

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.

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'.

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)?

[FUT na pl.comp.programming bo to chyba jednak bardziej programowania
się tyczy - choć w sumie to nie wiem]

--
<:> Roger, MoonWolf Out <:>|Victims falling under chains
(::) (::)|
(:) JID:m...@j...org(:)| http://karakkhaz.prv.pl

do góry

> 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.

Tu trzeba by wiedzieć jakie będą rzeczywiste dane.
Jeśli naprawdę będą się bardzo rzadko zmieniać (np. skan co 10 s ale
zmiana co godzinę), to wg mnie lepiej jest "upakowywać". Jeśli dane
zmieniają się częściej niż co 300-500 skanów (może rzadziej), to sądzę,
że lepiej wpisywać dane po każdym skanie.
Rocznie będziesz miał 365*24*60*6 = 3 153 600 wpisów. To nie jest dużo i
generowanie zakresów danych do wykresów będzie łatwe i szybkie.

Zastanowił bym się czy robić osobną tabelę dla innej zmiennej. Raczej
nie. Zwłaszcza, że "będzie tego nieokreślona liczba - na pewno będą
przybywać". Dołóż jedną kolumnę "nazwa zmiennej" i trzymaj wszystko w
jednej tabeli.

--
pozdrawiam
Krzysztof Jodłowski

WYSYŁKOWO.PL - Sklep Internetowy
http://www.wysylkowo.pl

do góry

Krzysztof Jodłowski denied rebel lies:

> Tu trzeba by wiedzieć jakie będą rzeczywiste dane.
> Jeśli naprawdę będą się bardzo rzadko zmieniać (np. skan co 10 s ale
> zmiana co godzinę), to wg mnie lepiej jest "upakowywać". Jeśli dane
> zmieniają się częściej niż co 300-500 skanów (może rzadziej), to
> sądzę, że lepiej wpisywać dane po każdym skanie.

Różnie. Niektóre będa się zmieniać praktycznie za każdym razem,
niektóre prawie wcale.

> Rocznie będziesz miał 365*24*60*6 = 3 153 600 wpisów. To nie jest
> dużo i generowanie zakresów danych do wykresów będzie łatwe i
> szybkie.

Jeszcze trzeba pomnożyć przez liczbę danych z jednego źródła (kilka -
kilkanaście) i ewentualnie liczbę źródeł (powoli rosnącą).

> Zastanowił bym się czy robić osobną tabelę dla innej zmiennej. Raczej
> nie. Zwłaszcza, że "będzie tego nieokreślona liczba - na pewno będą
> przybywać". Dołóż jedną kolumnę "nazwa zmiennej" i trzymaj wszystko w
> jednej tabeli.

Może nieprecyzyjnie się wyraziłem - tak właśnie będzie. Każda tabela
będzie miała wiele danych, ale pochodzących z jednego źródła. Źródeł
będzie wiele (konkretniej - to są parametry urządzeń, jedna tabela na
urządzenie).

--
<:> Roger, MoonWolf Out <:>|I don't understand. It
(::) (::)|should be dead by now.
(:) JID:m...@j...org(:)| http://karakkhaz.prv.pl

do góry

W dniu 13.05.2011 09:34, MoonWolf pisze:
> Pytanie jest takie: czy warto (a jeśli tak to w jakich okolicznościach)
> 'upakowywać' dane składowane w bazie
Warto, w sytuacji gdy różnica to np. 1 a 100 GB danych rocznie.

Warto pomyśleć też czy RRD nie będzie lepszym rozwiązaniem.

> 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.
Tutaj uwaga - jeżeli generujesz wykres z wielu lat to nawet gdy masz
miliony rekordów to potrzebujesz w jednej chwili max tysiąca. Dobrze
napisane widoki w bazie pozwolą policzyć średnie na miejscu i przesłać z
bazy do aplikacji tylko te dane, które są potrzebne.

> I w ogóle
> pachnie to 'premature optimization'.
Tak.

> 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)?
Tak. Użycie SQLITE może być złym pomysłem jeżeli sumarycznie będzie
wiele zapisów na sekundę. Użycie postgresa może być dobrym pomysłem. To
się nazywa "analiza wymagań" i za darmo jej za Ciebie robić nie będę.

--
Pozdrawiam
Michoo

do góry

MoonWolf napisał(a):
> Mamy w firmie różnice zdań i chciałem się zorientować w pewnej kwestii.
>
> 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ć).

SQL Antipatterns, Metadata Tribbles

http://www.slideshare.net/billkarwin/sql-antipattern
s-strike-back
slajdy 5 do 16

> 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'.

IMHO mają rację.

> 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)?

Tak. Być może nie potrzebujesz SQLa, tylko RRD. A jeśli potrzebujesz
SQLa, to warto wybrać RDBMS umożliwiającego partycjonowanie danych i
tworzenie indeksów częściowych (http://en.wikipedia.org/wiki/Partial_index)

> [FUT na pl.comp.programming bo to chyba jednak bardziej programowania
> się tyczy - choć w sumie to nie wiem]

Nie czytam, ale jak uważasz ;) FUT respektuję.

--
Daniel Podlejski

do góry

Michoo denied rebel lies:

>> 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)?
> Tak. Użycie SQLITE może być złym pomysłem jeżeli sumarycznie będzie
> wiele zapisów na sekundę. Użycie postgresa może być dobrym pomysłem.
> To się nazywa "analiza wymagań" i za darmo jej za Ciebie robić nie
> będę.

Tego nie oczekuję - wystarczy 'Tak'. Dziękuję.

--
<:> Roger, MoonWolf Out <:>|And now, Princess, we will
(::) (::)|discuss the location of the
(:) JID:m...@j...org(:)|hidden Rebel Base

do góry

>> Rocznie będziesz miał 365*24*60*6 = 3 153 600 wpisów. To nie jest
>> dużo i generowanie zakresów danych do wykresów będzie łatwe i
>> szybkie.
>
> Jeszcze trzeba pomnożyć przez liczbę danych z jednego źródła (kilka -
> kilkanaście) i ewentualnie liczbę źródeł (powoli rosnącą).

Przyjmijmy:
Liczba danych z jednego źródła = np. 10 i liczba źródeł na początek = 20.
To daje 3153600 * 10 * 20 = 360 mln na rok. To dalej nie jest duża
liczna biorąc pod uwagę ilość kolumn i (chyba) wielkość pola dane".
Wyjdzie tego np. 4-5 GB na rok.

>> Zastanowił bym się czy robić osobną tabelę dla innej zmiennej. Raczej
>> nie. Zwłaszcza, że "będzie tego nieokreślona liczba - na pewno będą
>> przybywać". Dołóż jedną kolumnę "nazwa zmiennej" i trzymaj wszystko w
>> jednej tabeli.
>
> Może nieprecyzyjnie się wyraziłem - tak właśnie będzie. Każda tabela
> będzie miała wiele danych, ale pochodzących z jednego źródła. Źródeł
> będzie wiele (konkretniej - to są parametry urządzeń, jedna tabela na
> urządzenie).

Czyli dalej podtrzymuje. Kolumny: Data, Id zmiennej, Wartosc, Id źródła.

Resztę chyba opisali Michoo i Daniel. Partycjonowanie, jakieś indeksiki
i parę innych błahostek :)


--
pozdrawiam
Krzysztof Jodłowski

WYSYŁKOWO.PL - Sklep Internetowy
http://www.wysylkowo.pl

do góry

MoonWolf wrote:

> Mamy w firmie różnice zdań i chciałem się zorientować w pewnej kwestii.
>
> 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ć).
>

A dlaczego tak?
To mi pachnie modelem EAV - nie lepiej dla kazdej "danej" oddzielna relacje
(tabele)?

> 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 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. Dodatkowo istotna jest jeszcze informacja o czasie ostatniego
odczytu.
(Powyzsze jest tylko wnioskiem z tego, ze istnieje mozliwosc "upakowania")
Jezeli istotny jest fakt, ze nastapila _zmiana_ wartosci (a nie wartosc sama
w sobie) to moze w ogole inny model jest potrzebny?

>
> Z danych tych będą sporządzane wykresy

LOL - no jasne ze beda jakies zestawienia (byc moze w postaci wykresow) - w
koncu po cos te dane sa przechowywane.

A tak powaznie - w zaleznosci od tego jakie te wykresy (czyli co z bazy
chcesz wyciagnac), model danych bedzie inny.

> (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'.

Tak.

>
> 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)?

Oczywiscie.

--
Michal

do góry

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).

>> 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.

--
<:> Roger, MoonWolf Out <:>|Do undo others as they have
(::) (::)|done to you
(:) JID:m...@j...org(:)| http://karakkhaz.prv.pl

do góry

> Bo wtedy można te wartości odtworzyć (poza bazą danych) mając daty
> zmian.

Tracimy tylko informację, czy zapisy w ogóle były, czy też była np.
awaria i nie było zapisów. Ale to szczegół i można go obejść wpisując w
przypadku awarii dane charakterystyczne (kwestia skryptu zbierającego dane).

--
Krzysztof

do góry