🚀 go-pugleaf

W dniu 2018-02-08 o 17:36, irq pisze:
> 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.

Idąc tym tropem, to faktycznie lepiej porzucić model relacyjny na rzecz 
np. czegoś takiego:
https://www.mongodb.com/json-and-bson

I, imo, ma to sens w tym konkretnym zastosowaniu.
Jednakże wymaga to większego nakładu na oprogramowanie całego mechanizmu.
Za to dostajemy super-duper elastyczny model danych.

-- 
wloochacz

W dniu czwartek, 8 lutego 2018 18:15:51 UTC+1 użytkownik wloochacz napisał:
> W dniu 2018-02-08 o 17:36, irq pisze:
> > 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.
> 
> Idąc tym tropem, to faktycznie lepiej porzucić model relacyjny na rzecz 
> np. czegoś takiego:
> https://www.mongodb.com/json-and-bson

ojtam od razu mongodb. Jeżeli już json, kolega chce stosować PostgreSQL, a tam ma typ json/jsonb. A model relacyjny i tak będzie potrzebny do raportowań i kojarzenia czujników z ich lokalizacjami.

>....Do składowania przygotuj sobie jak najprostszą, być może 
>partycjonowaną, tabelę pomiarów, zawierającą pary klucz-wartość, ...
Zupełnie się nie zgadzam,
!!___ale upierać się nie będę bo nie widziałam danyh, jakie ten pan będzie 
obrabiał, a to jest kluczowe._____!!

Zaglądam zaś dość często na strony pokazujące smog.
I widzę na raz x wartości. One są z jednego czujnika.
Brak tam np wiatru. Tego nie ma w czujce, jest gdzieś osobno.
Więc część danyh jest "razem" inne dane osobno.
MImo, że pewne wyjątkowe dane jak wiatr są osobno, ja bym dla tego 
zastosowania wybrała model prymitywny:
Tabela:
czas i miejsce pomiaru (miejsce pomiaru = czujnik) i wiele kolumn z 
wartościami (wilgotność, temperatura, smog, taki , a taki....)
i dodała kolumnę wiatr itp.
Wspułczesne bazy zwykle pozwalają prosto dodać kolejną kolumnę jakby się 
pojawiła nowa dana np zawartość SO2.
Osobne tabele to np tabela czujek, miejsc itp.

-- 
(tekst bez: ó, ch, rz i -ii)
Ortografia to NAWYK, często nielogiczny, ktury ludzie ociężali umysłowo,
nażucają bezmyślnie następnym pokoleniom. ( ortografia . pev . pl )

W dniu czwartek, 8 lutego 2018 19:59:38 UTC+1 użytkownik Stokrotka napisał:
> Wspułczesne bazy zwykle pozwalają prosto dodać kolejną kolumnę jakby się 
> pojawiła nowa dana np zawartość SO2.

zupełnie tak samo jak Excel, prawda?

W dniu 08.02.2018 o 17:36, irq pisze:
 > 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.
Najpewniej tak zrobię. Najpierw prosto zebrać dane a później zastanowić 
się co z nimi zrobić.

 > 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).
W zasadzie to nie interesuje mnie czy jest to ten sam czujnik co rok 
temu. Liczy się czy jest mierzona ta sama wartość w tym samym miejscu 
(np. temperatura powietrza na zewnątrz w lokalizacji B).

>> Wspułczesne bazy zwykle pozwalają prosto dodać kolejną kolumnę jakby się
>> pojawiła nowa dana np zawartość SO2.

>zupełnie tak samo jak Excel, prawda?

Jak nie masz argumentu i nie umiesz pozostaje ci poniżanie.
Ale i tego nie umiesz. W Excelu nie ma typu danej, gdy dodajesz kolumnę,
a bazie danyh, w tabeli jest zawsze dla każdej kolumny.

Faktem jest jednak, że z bazy można zrobić export do exela i użyć gotowego 
nażędzie do wykresu.


-- 
(tekst bez: ó, ch, rz i -ii)
Ortografia to NAWYK, często nielogiczny, ktury ludzie ociężali umysłowo,
nażucają bezmyślnie następnym pokoleniom. ( ortografia . pev . pl )

W dniu 2018-02-08 o 18:36, irq pisze:
/ciach/

> ojtam od razu mongodb. Jeżeli już json, kolega chce stosować PostgreSQL, a tam ma typ json/jsonb. 
JSON w PostreSQL (i każdej innej relacyjnej bazie danych) to taka koza 
co nie jest koniem.

Pewnie, można i na kozie dojechać...

> A model relacyjny i tak będzie potrzebny do raportowań i kojarzenia czujników z ich lokalizacjami.
A niby dlaczego jest potrzebny, czyli niezbędny?

-- 
wloochacz

W dniu piątek, 9 lutego 2018 14:43:52 UTC+1 użytkownik wloochacz napisał:
> W dniu 2018-02-08 o 18:36, irq pisze:
> /ciach/
> 
> > A model relacyjny i tak będzie potrzebny do raportowań i kojarzenia czujników z ich lokalizacjami.
> A niby dlaczego jest potrzebny, czyli niezbędny?

Wynika to z tego fragmentu mojej wypowiedzi, który ciachnąłeś. Uniezależnienie lokalizacji pomiaru od niekoniecznie stałej lokalizacji czujników. Z późniejszych wypowiedzi kolegi pytającego wynika, że raczej o to nie dba, bo buduje mały system, w którym może to nie mieć miejsca, ani znaczenia. Ja założyłem, że może to być dowolnie duży i nadający się do elastycznej rozbudowy system, w którego ekspolatacji trzeba spróbować przewidzieć takie rzeczy jak zarządzanie ruchem i migracjami elementów jego wyposażenia. A zatem pomiar z identyfikatorem konkretnego czujnika z dzisiaj i pomiar z tym samym identyfikatorem za rok, to niekoniecznie muszą być pomiary dotyczące tego samego miejsca.

W dniu piątek, 9 lutego 2018 14:43:52 UTC+1 użytkownik wloochacz napisał:
> JSON w PostreSQL (i każdej innej relacyjnej bazie danych) to taka koza 
> co nie jest koniem.
> 
> Pewnie, można i na kozie dojechać...
> 

Czy mógłbyś wyjaśnić szerzej ten pogląd?

W dniu 2018-02-08 o 21:23, irq pisze:
> W dniu czwartek, 8 lutego 2018 19:59:38 UTC+1 użytkownik Stokrotka napisał:
>> Wspułczesne bazy zwykle pozwalają prosto dodać kolejną kolumnę jakby się
>> pojawiła nowa dana np zawartość SO2.
> 
> zupełnie tak samo jak Excel, prawda?
> 
przegiąłeś :)))
Chyba kumasz o co chodzi.

-- 
Artur

W dniu 2018-02-09 o 00:48, baItiz pisze:
> W dniu 08.02.2018 o 20:15, Adam M pisze:
>> 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.
> 
> To chyba jest najlepszy pomysł. Najpierw prosto zbierać dane a później 
> zastanowić się co i jak z nimi zrobić.
> 
brawo
> Strumień danych nie będzie duży. Docelowo co minutę do 50 wartości pomiarów 
> z 3 lokalizacji. W każdej lokalizacji czujniki będą komunikowały się z 
> bramką a ta dopiero wysyłała dane dalej. W razie potrzeby można na poziomie 
> bramki wprowadzić agregację i wysyłać uśrednione dane co 5 min.
drugi raz btawo

-- 
Artur

W dniu 2018-02-09 o 19:56, irq pisze:
> W dniu piątek, 9 lutego 2018 14:43:52 UTC+1 użytkownik wloochacz napisał:
>> JSON w PostreSQL (i każdej innej relacyjnej bazie danych) to taka koza
>> co nie jest koniem.
>>
>> Pewnie, można i na kozie dojechać...
>>
> 
> Czy mógłbyś wyjaśnić szerzej ten pogląd?
To oczywiste, rozwiązania uniwersalne nie są najlepsze w każdym 
przypadku, tylko uniwersalne.

Innymi słowy - żadna baza relacyjna nie będzie równie 
wydajna/zaawansowana w przetwarzaniu danych nierelacyjnych, jak 
dedykowane do tego rozwiązanie NoSQLowe.

-- 
wloochacz

W dniu 2018-02-09 o 19:55, irq pisze:
> W dniu piątek, 9 lutego 2018 14:43:52 UTC+1 użytkownik wloochacz napisał:
>> W dniu 2018-02-08 o 18:36, irq pisze:
>> /ciach/
>>
>>> A model relacyjny i tak będzie potrzebny do raportowań i kojarzenia czujników z ich lokalizacjami.
>> A niby dlaczego jest potrzebny, czyli niezbędny?
> 
> Wynika to z tego fragmentu mojej wypowiedzi, który ciachnąłeś. 
No cóż, nie zgadzam się z tym w ogóle.

> Uniezależnienie lokalizacji pomiaru od niekoniecznie stałej lokalizacji czujników. Z późniejszych wypowiedzi kolegi pytającego wynika, że raczej o to nie dba, bo buduje mały system, w którym może to nie mieć miejsca, ani znaczenia. Ja założyłem, że może to być dowolnie duży i nadający się do elastycznej rozbudowy system, w którego ekspolatacji trzeba spróbować przewidzieć takie rzeczy jak zarządzanie ruchem i migracjami elementów jego wyposażenia. A zatem pomiar z identyfikatorem konkretnego czujnika z dzisiaj i pomiar z tym samym identyfikatorem za rok, to niekoniecznie muszą być pomiary dotyczące tego samego miejsca.

I właśnie dlatego rozwiązania NoSQL w tym przypadku mogą pokazać swoją 
przydatność i przewagę w stosunku do baz relacyjnych.
Mówić krótko - jeśli mamy ustandaryzowany model danych o zerowej lub 
niewielkiej dynamice zmian schematu danych, bazy relacyjne pewnie będą 
lepsze.

Tu wskazujesz dokładnie coś odwrotnego.
Proponowany model EAV (zwany antywzorcem Entity Attribute Value) dla baz 
relacyjnych to zabójstwo dla ich wydajności, zwłaszcza przy 
niebagatelnej ilości danych.

A w omawianym przypadku sam podniosłeś dokładnie takie wymagania ;-)

-- 
wloochacz

W dniu sobota, 10 lutego 2018 17:23:21 UTC+1 użytkownik wloochacz napisał:
> W dniu 2018-02-09 o 19:55, irq pisze:
> > W dniu piątek, 9 lutego 2018 14:43:52 UTC+1 użytkownik wloochacz napisał:
> >> W dniu 2018-02-08 o 18:36, irq pisze:
> >> /ciach/
> >>
> >>> A model relacyjny i tak będzie potrzebny do raportowań i kojarzenia czujników z ich lokalizacjami.
> >> A niby dlaczego jest potrzebny, czyli niezbędny?
> > 
> > Wynika to z tego fragmentu mojej wypowiedzi, który ciachnąłeś. 
> No cóż, nie zgadzam się z tym w ogóle.
> 
> > Uniezależnienie lokalizacji pomiaru od niekoniecznie stałej lokalizacji czujników. Z późniejszych wypowiedzi kolegi pytającego wynika, że raczej o to nie dba, bo buduje mały system, w którym może to nie mieć miejsca, ani znaczenia. Ja założyłem, że może to być dowolnie duży i nadający się do elastycznej rozbudowy system, w którego ekspolatacji trzeba spróbować przewidzieć takie rzeczy jak zarządzanie ruchem i migracjami elementów jego wyposażenia. A zatem pomiar z identyfikatorem konkretnego czujnika z dzisiaj i pomiar z tym samym identyfikatorem za rok, to niekoniecznie muszą być pomiary dotyczące tego samego miejsca.
> 
> I właśnie dlatego rozwiązania NoSQL w tym przypadku mogą pokazać swoją 
> przydatność i przewagę w stosunku do baz relacyjnych.
> Mówić krótko - jeśli mamy ustandaryzowany model danych o zerowej lub 
> niewielkiej dynamice zmian schematu danych, bazy relacyjne pewnie będą 
> lepsze.
> 
> Tu wskazujesz dokładnie coś odwrotnego.
> Proponowany model EAV (zwany antywzorcem Entity Attribute Value) dla baz 
> relacyjnych to zabójstwo dla ich wydajności, zwłaszcza przy 
> niebagatelnej ilości danych.
> 
> A w omawianym przypadku sam podniosłeś dokładnie takie wymagania ;-)
> 
tak, ale w odniesieniu do samej tabeli (struktury? systemu?) przechowującej pierwotne dane, w odniesieniu do których nie jeszcze ma pełnej wiedzy co do ich kształtu i zakresu spodziewanych zmian. Model relacyjny może zaś znaleźć zastosowanie zakresie organizacji danych do wydajnego ich raportowania. I tu właśnie, nawiązując do sąsiedniej Twojej odpowiedzi, PostgreSQL z typem, podkreślam: typem danych json, może być doskonałym środowiskiem do realizacji takiego hybrydowego rozwiązania.

On 10.02.2018 17:55, irq wrote:
> W dniu sobota, 10 lutego 2018 17:23:21 UTC+1 użytkownik wloochacz napisał:
>> Tu wskazujesz dokładnie coś odwrotnego.
>> Proponowany model EAV (zwany antywzorcem Entity Attribute Value) dla baz
>> relacyjnych to zabójstwo dla ich wydajności, zwłaszcza przy
>> niebagatelnej ilości danych.
>>
>> A w omawianym przypadku sam podniosłeś dokładnie takie wymagania ;-)
>>
> tak, ale w odniesieniu do samej tabeli (struktury? systemu?) przechowującej pierwotne dane, w odniesieniu do których nie jeszcze ma pełnej wiedzy co do ich kształtu i zakresu spodziewanych zmian.

przecież wiadomo jakie będą dane... czujnik, wielkość fizyczna, wartość 
+ może jakieś timestampy...

> Model relacyjny może zaś znaleźć zastosowanie zakresie organizacji danych do wydajnego ich raportowania.

ze znormalizowanych danych w bazie relacyjnej też dobrze się raportuje 
(pytam w kontekście "wydajnego")?

> I tu właśnie, nawiązując do sąsiedniej Twojej odpowiedzi, PostgreSQL z typem, podkreślam: typem danych json, może być doskonałym środowiskiem do realizacji takiego hybrydowego rozwiązania.

a ma on jakąś przewagę nad xml-em (też obsługiwanym w bazie relacyjnej)?

pozdrawiam
geos

W dniu sobota, 10 lutego 2018 17:23:21 UTC+1 użytkownik wloochacz napisał:
> W dniu 2018-02-09 o 19:55, irq pisze:
> > W dniu piątek, 9 lutego 2018 14:43:52 UTC+1 użytkownik wloochacz napisał:
> >> W dniu 2018-02-08 o 18:36, irq pisze:
> >> /ciach/
> >>
> >>> A model relacyjny i tak będzie potrzebny do raportowań i kojarzenia czujników z ich lokalizacjami.
> >> A niby dlaczego jest potrzebny, czyli niezbędny?
> > 
> > Wynika to z tego fragmentu mojej wypowiedzi, który ciachnąłeś. 
> No cóż, nie zgadzam się z tym w ogóle.
> 
> > Uniezależnienie lokalizacji pomiaru od niekoniecznie stałej lokalizacji czujników. Z późniejszych wypowiedzi kolegi pytającego wynika, że raczej o to nie dba, bo buduje mały system, w którym może to nie mieć miejsca, ani znaczenia. Ja założyłem, że może to być dowolnie duży i nadający się do elastycznej rozbudowy system, w którego ekspolatacji trzeba spróbować przewidzieć takie rzeczy jak zarządzanie ruchem i migracjami elementów jego wyposażenia. A zatem pomiar z identyfikatorem konkretnego czujnika z dzisiaj i pomiar z tym samym identyfikatorem za rok, to niekoniecznie muszą być pomiary dotyczące tego samego miejsca.
> 
> I właśnie dlatego rozwiązania NoSQL w tym przypadku mogą pokazać swoją 
> przydatność i przewagę w stosunku do baz relacyjnych.
> Mówić krótko - jeśli mamy ustandaryzowany model danych o zerowej lub 
> niewielkiej dynamice zmian schematu danych, bazy relacyjne pewnie będą 
> lepsze.

w tym przypadku mamy model, po którym nie powinniśmy się spodziewać wysokiej dynamiki zmian. No chyba, że rzeczywiście pojawi się wymóg rejestrowania stężenia SO2 :)

> 
> Tu wskazujesz dokładnie coś odwrotnego.
> Proponowany model EAV (zwany antywzorcem Entity Attribute Value) dla baz 
> relacyjnych to zabójstwo dla ich wydajności, zwłaszcza przy 
> niebagatelnej ilości danych.

zabójstwo, ale nie dla wydajności bazy danych, a wydajności "modelu dostępu" do tablicy skonstruowanej z zastosowaniem EAV. Jeżeli ktoś się uprze raportować dane w oparciu o odczyt z jedynej samotnej tabeli z zapisem surowych próbek to żaden model nie będzie wydajny. 

> 
> A w omawianym przypadku sam podniosłeś dokładnie takie wymagania ;-)
> 

tak, ale w odniesieniu do samej tabeli przechowującej pierwotne dane, w odniesieniu do których nie jeszcze ma pełnej wiedzy co do ich kształtu i zakresu spodziewanych zmian. Pełny model relacyjny może zaś znaleźć zastosowanie w zakresie organizacji danych do wydajnego ich raportowania. 

I tu właśnie, nawiązując do sąsiedniej Twojej odpowiedzi, PostgreSQL z typem, podkreślam: typem danych json, może być doskonałym środowiskiem do realizacji takiego hybrydowego rozwiązania. Chciałem wypowiadać się zwięźle - dlatego użyłem skrótu EAV jako hasłowego określenia, ale nie było to najszczęśliwsze posunięcie. Dlatego chętnie przeszedłem na używanie skrótu JSON, zwłaszcza w kontekście typu danych json (jsonb) w postgresie.

Definicja tabeli próbek danych mogłaby być taka jak:

CREATE TABLE data_sample (
    id          bigserial PRIMARY KEY,
    dt          timestamp,
    sensor_id   integer, -- albo text? - prawdopodobnie powtórzenie któregoś elementu z sample - celowy nadmiar dla usprawnienia agregacji i dostępu
    sample      json     -- albo jsonb - i tutaj dowolna struktura
);
-- i być może:
CREATE INDEX ON data_sample (date_trunc('day', dt), sensor_id);
-- zamiast 'day' - może 'hour'?, 'week'? - zależnie od potrzeb.

"dt" oraz "sensor_id" są uchwytami do modelu relacyjnego i przetwarzania danych w kierunku ich przygotowania do raportowania. "sample" zawiera całą pozostałą, nie w pełni zdefiniowaną jeszcze, zawartość danych.

Tak jak pisałem wcześniej, warto rozważyć partycjonowanie tej tabeli (wg, tygodni? miesięcy? lat?).

On 10.02.2018 19:02, irq wrote:
> Definicja tabeli próbek danych mogłaby być taka jak:
>
> CREATE TABLE data_sample (
>     id          bigserial PRIMARY KEY,
>     dt          timestamp,
>     sensor_id   integer, -- albo text? - prawdopodobnie powtórzenie któregoś elementu z sample - celowy nadmiar dla usprawnienia agregacji i dostępu
>     sample      json     -- albo jsonb - i tutaj dowolna struktura
> );

a taka byłaby niedobra?

CREATE TABLE data_sample (
   sensor_id ..
, dt timestamp default systimestamp
, wielkość_fizyczna varchar2(..)
, value varchar2(..) )

po co w swojej tabeli masz id skoro jest naturalny klucz główny 
(sensor_id, dt)?

> "dt" oraz "sensor_id" są uchwytami do modelu relacyjnego i przetwarzania danych w kierunku ich przygotowania do raportowania. "sample" zawiera całą pozostałą, nie w pełni zdefiniowaną jeszcze, zawartość danych.

co to jest "uchwyt do modelu relacyjnego"? przeczytałem kilka książek o 
bazach relacyjnych ale nie spotkałem się z takim określeniem.

pozdrawiam,
geos

W dniu sobota, 10 lutego 2018 19:00:02 UTC+1 użytkownik geos napisał:
> On 10.02.2018 17:55, irq wrote:
> > W dniu sobota, 10 lutego 2018 17:23:21 UTC+1 użytkownik wloochacz napisał:
> >> Tu wskazujesz dokładnie coś odwrotnego.
> >> Proponowany model EAV (zwany antywzorcem Entity Attribute Value) dla baz
> >> relacyjnych to zabójstwo dla ich wydajności, zwłaszcza przy
> >> niebagatelnej ilości danych.
> >>
> >> A w omawianym przypadku sam podniosłeś dokładnie takie wymagania ;-)
> >>
> > tak, ale w odniesieniu do samej tabeli (struktury? systemu?) przechowującej pierwotne dane, w odniesieniu do których nie jeszcze ma pełnej wiedzy co do ich kształtu i zakresu spodziewanych zmian.
> 
> przecież wiadomo jakie będą dane... czujnik, wielkość fizyczna, wartość 
> + może jakieś timestampy...
> 
> > Model relacyjny może zaś znaleźć zastosowanie zakresie organizacji danych do wydajnego ich raportowania.
> 
> ze znormalizowanych danych w bazie relacyjnej też dobrze się raportuje 
> (pytam w kontekście "wydajnego")?

nie zawsze. Bywa pomocna celowa denormalizacja.

> 
> > I tu właśnie, nawiązując do sąsiedniej Twojej odpowiedzi, PostgreSQL z typem, podkreślam: typem danych json, może być doskonałym środowiskiem do realizacji takiego hybrydowego rozwiązania.
> 
> a ma on jakąś przewagę nad xml-em (też obsługiwanym w bazie relacyjnej)?

niekoniecznie. Może decydować zestaw operatorów i funkcji (i ich wydajność) dostępnych dla tych typów. A także osobiste preferencje. Czy chociażby fakt, że dane z czujnika mają format xml albo json.

Kolego, odniosłem wrażenie, że czepiasz się sczegółów, jakbyś chciał mnie przeegzaminować. Jeżeli naprawdę tego chesz i się postarasz, to zapewniam Cię, że obleję. Przykłady które napisałem, nie są projektem, a lużną ilustracją. Ponieważ zadałeś pytania i piszemy publicznie, poniżej odpowiadam, choć nie mam ochoty angażować się w utarczki.

W dniu sobota, 10 lutego 2018 19:14:09 UTC+1 użytkownik geos napisał:
> On 10.02.2018 19:02, irq wrote:
> > Definicja tabeli próbek danych mogłaby być taka jak:
> >
> > CREATE TABLE data_sample (
> >     id          bigserial PRIMARY KEY,
> >     dt          timestamp,
> >     sensor_id   integer, -- albo text? - prawdopodobnie powtórzenie któregoś elementu z sample - celowy nadmiar dla usprawnienia agregacji i dostępu
> >     sample      json     -- albo jsonb - i tutaj dowolna struktura
> > );
> 
> a taka byłaby niedobra?
> 
> CREATE TABLE data_sample (
>    sensor_id ..
> , dt timestamp default systimestamp
> , wielkość_fizyczna varchar2(..)
> , value varchar2(..) )

byłaby równie dobra, a przede wszystkim uniwersalna. Uczepiłem się postgresa, bo autor wątku wymienił go pośród preferowanych systemów. A skoro jest w nim typ json, z całym zestawem stojących za nim funkcji i operatorów (np. sample->'wielkość_fizyczna') to zaproponowałem właśnie ten typ. 

> 
> po co w swojej tabeli masz id skoro jest naturalny klucz główny 
> (sensor_id, dt)?

czytałem w jakieś książce o relacyjnych bazach danych, że naturalne klucze główne są niedobre. Nie pamiętam szczegółów, pamiętam zasadę o przynajmniej starannym rozważeniu takiej decyzji. Jednak to co piszesz może mieć sens, a książka którą czytałem mało wybitna. Niewykluczone więc, że po wnikliwej analizie można podjąć decyzję projektową o zastosowaniu (sensor_id, dt) jako klucza głównego.

> 
> > "dt" oraz "sensor_id" są uchwytami do modelu relacyjnego i przetwarzania danych w kierunku ich przygotowania do raportowania. "sample" zawiera całą pozostałą, nie w pełni zdefiniowaną jeszcze, zawartość danych.
> 
> co to jest "uchwyt do modelu relacyjnego"? przeczytałem kilka książek o 
> bazach relacyjnych 

Bez złośliwości - czy mógłbyś podać tytuły? Na pewno nie o każdej słyszałem, więc pewnie skorzystam. Czy którąś szczególnie polecasz? 

> ale nie spotkałem się z takim określeniem.

też go nie spotkałem, a wymyśliłem go doraźnie, dla zwięzłości, chcąc oddać sens rozgraniczenia pomiędzy "częścią relacyjną" a "częścią nierelacyjną" "modelu hybrydowego", który wyłonił się w toku rozwoju dyskusji. Nie pytaj mnie, proszę, o sens tych określeń i nie wyszukuj ich wystąpień w literaturze, bo prawdopodobnie ich tam nie ma. Zauważ jednak, że pojawiła się tutaj jakby próba połączenia dwóch tradycyjnie skonfliktowanych światów SQL i NoSQL i problem z terminologią jakiej by w tych rozważaniach można było użyć.

Dla (nieformalnej) ilustracji tego "uchwytu" i w nawiązaniu do "tablicy ewidencji czujników", o której pisałem wcześniej:

CREATE TABLE sensor (
    id          serial PRIMARY KEY, -- nie pytaj
    sensor_id   integer           , -- a może text? 
    start       timestamp         , -- kiedy zainstalowany
    stop        timestamp DEFAULT 'infinity', -- kiedy zabrany
    location    text, -- "jakiś adres, albo współrzędne"
);

Działanie owego "uchwytu" można wyrazić poprzez:

SELECT  d.dt,
        d.location,
        s.sample->'temperatura' AS temperatura,
        s.sample->'wiatr'       AS wiatr
FROM    data_sample d
JOIN    sensor s
ON      d.sensor_id = s.sensor_id
    AND d.dt BETWEEN s.start AND s.stop

Ponownie - nie aspiruje ten przykład do bycia optymalnym ani niekoniecznie obrazuje złączenie z całą tabelą data_sample. To ilustracja. 

Przepraszam za nadużycie skrótu myślowego.

On 10.02.2018 21:13, irq wrote:
> Kolego, odniosłem wrażenie, że czepiasz się sczegółów, jakbyś chciał mnie przeegzaminować. Jeżeli naprawdę tego chesz i się postarasz, to zapewniam Cię, że obleję. Przykłady które napisałem, nie są projektem, a lużną ilustracją. Ponieważ zadałeś pytania i piszemy publicznie, poniżej odpowiadam, choć nie mam ochoty angażować się w utarczki.

po prostu zadaję pytania do tego co napisałeś. zaintrygowało mnie to. 
sam napisałem niewiele w tym wątku... :( nie lubisz pytań? uraziły Cię?

>> ale nie spotkałem się z takim określeniem.
>
> też go nie spotkałem, a wymyśliłem go doraźnie, dla zwięzłości, chcąc oddać sens rozgraniczenia pomiędzy "częścią relacyjną" a "częścią nierelacyjną" "modelu hybrydowego", który wyłonił się w toku rozwoju dyskusji.

jak to rozumieć? czy "część relacyjna" i "część nierelacyjna" bazy 
relacyjnej zależy od typu danych użytych w relacji? uściślij proszę.

mam jeszcze pytanie o tę część wypowiedzi:

> Do składowania przygotuj sobie jak najprostszą, być może partycjonowaną, tabelę pomiarów

dla tabeli partycjonowanej system operacyjny musi utrzymywać kilka 
uchwytów danych (zamiast np. jednego). czy w takim razie sugerowane 
partycjonowanie nie stoi poniekąd w kontrze do "najprostszego"?

czy sugerowanie złożonego typu danych json, do którego obsługi potrzebny 
jest trochę bardziej skomplikowany mechanizm niż do obsługi typów 
prostych, ma jakąś przewagę nad zastosowaniem właśnie typów prostych do 
składowania danych w opisywanym przypadku kilku rejestratorów? czy 
stosowanie typu złożonego również nie jest w kontrze do "najprostszego"?

pozdrawiam,
geos

On 09.02.2018 00:48, baItiz wrote:
> W dniu 08.02.2018 o 20:15, Adam M pisze:
>> 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.
>
> To chyba jest najlepszy pomysł. Najpierw prosto zbierać dane a później
> zastanowić się co i jak z nimi zrobić.
>
> Strumień danych nie będzie duży. Docelowo co minutę do 50 wartości
> pomiarów z 3 lokalizacji. W każdej lokalizacji czujniki będą
> komunikowały się z bramką a ta dopiero wysyłała dane dalej. W razie
> potrzeby można na poziomie bramki wprowadzić agregację i wysyłać
> uśrednione dane co 5 min.

chyba powinieneś przemyśleć co chcesz zrobić. bo jak chcesz rejestrować 
strumień w sposób pewny to nie potrzebujesz do tego bazy. po prostu 
rejestrujesz to jako nieprzetworzony strumień danych z czujników. do 
tego potrzebujesz odpornego na błędy toru transmisji i metody 
składowania. do składowania z grubsza potrzebujesz macierzy 
odpowiedniego typu. to chyba wszystko. z 5 czujników rejestrujesz 5 
strumieni. będziesz miał rejestrację pewną, odporną na błędy i awarie. a 
później taki strumień sobie po prostu odpowiednio obrabiasz. żadna baza 
nie pomoże jak się coś po drodze "zesra" a może nawet przeszkadzać.

śmiem jednak wątpić czy to chcesz właśnie robić skoro piszesz na tę 
grupę. padły sugestie o użycie typów złożonych do danych. to nie to samo 
co "strumienie". odpowiedź sobie na pytanie, czy potrzebujesz nadać 
swoim danym strukturę złożoną albo czy czegoś brakuje typom prostym w 
tym konkretnym zastosowaniu. wtedy będziesz wiedział, czy potrzebujesz 
typów złożonych typu json, xml itp. powątpiewam, chociaż nie wykluczam, 
że mógłbyś tak chcieć w konkretnym celu, np. w celu późniejszej wymiany 
danych z innymi systemami jednym z popularnych standardów wymiany danych.

z tego co piszesz wnioskuję jednak, że wystarczą podstawowe typy proste. 
prawdopodobnie potrzebujesz również stosunkowo prostej relacyjnej bazy 
danych. sqllite by pewnie wystarczył z nawiązką. małe i sporo potrafi.

skoro wspominasz o "pewności zapisu" to przydałoby się coś z obsługą 
transakcji. ale pewnie świat się nie zawali gdy będzie nietransakcyjna 
bo prawdopodobnie w swoich rozważaniach uwzględniasz, że awarie się 
zdarzają i czujnik może się po prostu popsuć (i prawdopodobnie czujników 
nie duplikujesz aby zapobiec utracie danych, co nie?) co będzie miało 
finalny efekt taki sam jak transakcja, która się nie powiedzie - brak 
danych.

summa summarum temat "co minutę do 50 wartości z 3 lokalizacji" IMHO nie 
jest wart rozważań o partycjonowaniu, strumieniach, bazach nosql, typach 
złożonych i na dodatek nowej ortografii :) zrób to najprościej bez 
generowania zbędnych problemów: zbierz dane z czujnika, opakuj w 
inserta, wrzuć do tabeli, zakomituj.

pozdrawiam
geos

W dniu niedziela, 11 lutego 2018 01:32:26 UTC+1 użytkownik geos napisał:
> On 10.02.2018 21:13, irq wrote:
> > Kolego, odniosłem wrażenie, że czepiasz się sczegółów, jakbyś chciał mnie przeegzaminować. Jeżeli naprawdę tego chesz i się postarasz, to zapewniam Cię, że obleję. Przykłady które napisałem, nie są projektem, a lużną ilustracją. Ponieważ zadałeś pytania i piszemy publicznie, poniżej odpowiadam, choć nie mam ochoty angażować się w utarczki.
> 
> po prostu zadaję pytania do tego co napisałeś. zaintrygowało mnie to. 
> sam napisałem niewiele w tym wątku... :( nie lubisz pytań? uraziły Cię?

oprócz tego wskazywałeś na potknięcia w detalach, do których trudno przywiązywać wagę pisząc szybkiego posta, więc przypuszczałem, że próbowałeś mnie punktować, czy wykazać swoją przewagę. Wierzę, że się myliłem.

Czy podasz tytuły książek?

> 
> >> ale nie spotkałem się z takim określeniem.
> >
> > też go nie spotkałem, a wymyśliłem go doraźnie, dla zwięzłości, chcąc oddać sens rozgraniczenia pomiędzy "częścią relacyjną" a "częścią nierelacyjną" "modelu hybrydowego", który wyłonił się w toku rozwoju dyskusji.
> 
> jak to rozumieć? czy "część relacyjna" i "część nierelacyjna" bazy 
> relacyjnej zależy od typu danych użytych w relacji? uściślij proszę.
> 
> mam jeszcze pytanie o tę część wypowiedzi:
> 
> > Do składowania przygotuj sobie jak najprostszą, być może partycjonowaną, tabelę pomiarów
> 
> dla tabeli partycjonowanej system operacyjny musi utrzymywać kilka 
> uchwytów danych (zamiast np. jednego). czy w takim razie sugerowane 
> partycjonowanie nie stoi poniekąd w kontrze do "najprostszego"?

najprostsza - w sensie o jak najprostszej definicji, czyli liczby kolumn. Partycjonowanie jest niezależnym zagadnieniem, bo odnosi się do wielkości tabeli czyli liczby jej wierszy, o ile o tym samym partycjonowaniu mówimy. Jak zwykle - coś za coś - jeżeli danych zaczyna być za dużo, można szukać sposobów ich podziału, a komplikacja z tym związana jest ceną, którą trzeba rozważyć w ogólnym bilansie. Zasadniczo jednak partycjonowanie nie jest tym co powinniśmy rozważać w kontekście tego akurat wątku.

> 
> czy sugerowanie złożonego typu danych json, do którego obsługi potrzebny 
> jest trochę bardziej skomplikowany mechanizm niż do obsługi typów 
> prostych, ma jakąś przewagę nad zastosowaniem właśnie typów prostych do 
> składowania danych w opisywanym przypadku kilku rejestratorów?

w takim przypadku pewnie nie. Skoro jednak dyskutujemy, pomyślmy o przypadku, gdy jest to kilkaset lub kilka tysięcy rejestratorów, bo dopiero to jest ciekawe.

> czy 
> stosowanie typu złożonego również nie jest w kontrze do "najprostszego"?
> 

Nie jestem pewien, najlepiej byłoby przetestować. Tak na szybko - może oszczędzenie na liczbie wierszy? X wierszom par klucz: wartość jednego zestawu odczytów, w wersji z typami prostymi:

'yyyy-mm-dd', 'temperatura', '-11.1'
'yyyy-mm-dd', 'cisnienie', '1011'
...

odpowiada jeden wiersz z typem json:

'yyyy-mm-dd', '{"temperatura":"-11.1","cisnienie":"1101",...}' 

a więc jest jakiś powód aby odpuścić partycjonowanie.

W dniu poniedziałek, 5 lutego 2018 23:52:45 UTC+1 użytkownik baItiz napisał:
[... ciach]
> Co innego można zmienić w strukturze?

Bardzo dobrej rady udzielili już szanowni przedmówcy, potwierdzam z doświadczenia - rozdziel zbieranie danych od ich obróbki. W pierwszej części upewnij się, że zebrane surowe dane są kompletne, nic nie ginie, nie następują problemy w komunikacji (nie wiem z jakimi czujnikami pracujesz, czy transmisje danych przewidują jakieś sumy kontrolne pozwalające na wykrycie ewentualnych przekłamań, czy można zażądać ponownej transmisji itp.). 
Zbieraj te wartości jako tekst, konwersją pomartwisz się na etapie obróbki, równocześnie przechowując informację jaki rodzaj pomiaru i z jakiego urządzenia dostałeś w sposób umożliwiający późniejszą identyfikację.
Nikt Ci przecież nie zabroni na etapie obróbki zdefiniować sobie tabel pomocniczych, w których zdefiniujesz sobie Twoje czujniki, jakie pomiary wykonują, jaki rodzaj danych mogą zwracać czy też nawet jak te dane mogą być zinterpretowane. A później już do woli sobie generuj wydruki, wykresy czy czego tam dusza zapragnie.
Pozdrawiam
Rony

W dniu 11.02.2018 o 21:02, kuczek@kuczek.pl pisze:
> Bardzo dobrej rady udzielili już szanowni przedmówcy, potwierdzam z doświadczenia - rozdziel zbieranie danych od ich obróbki. W pierwszej części upewnij się, że zebrane surowe dane są kompletne, nic nie ginie, nie następują problemy w komunikacji (nie wiem z jakimi czujnikami pracujesz, czy transmisje danych przewidują jakieś sumy kontrolne pozwalające na wykrycie ewentualnych przekłamań, czy można zażądać ponownej transmisji itp.).

Czujniki własnej "produkcji" więc o wszystko będzie można zadbać. 
Planuję użycie protokołu MQTT z QOS 2. lub 1. co pozwoli na automatyczne 
ponawiane wysyłania w przypadku niepowodzenia.

> Zbieraj te wartości jako tekst, konwersją pomartwisz się na etapie obróbki, równocześnie przechowując informację jaki rodzaj pomiaru i z jakiego urządzenia dostałeś w sposób umożliwiający późniejszą identyfikację.
> Nikt Ci przecież nie zabroni na etapie obróbki zdefiniować sobie tabel pomocniczych, w których zdefiniujesz sobie Twoje czujniki, jakie pomiary wykonują, jaki rodzaj danych mogą zwracać czy też nawet jak te dane mogą być zinterpretowane. A później już do woli sobie generuj wydruki, wykresy czy czego tam dusza zapragnie.

Obecnie skłaniam się ku zapisywaniu surowych danych do MongoDB 
ewentualnie pójście w ekosystem Amazona: IoT Core / DynamoDB / Lambda

W dniu 11.02.2018 o 02:12, geos pisze:
> chyba powinieneś przemyśleć co chcesz zrobić. bo jak chcesz rejestrować 
> strumień w sposób pewny to nie potrzebujesz do tego bazy. po prostu 
> rejestrujesz to jako nieprzetworzony strumień danych z czujników. do 
> tego potrzebujesz odpornego na błędy toru transmisji i metody 
> składowania. do składowania z grubsza potrzebujesz macierzy 
> odpowiedniego typu. to chyba wszystko. z 5 czujników rejestrujesz 5 
> strumieni. będziesz miał rejestrację pewną, odporną na błędy i awarie. a 
> później taki strumień sobie po prostu odpowiednio obrabiasz. żadna baza 
> nie pomoże jak się coś po drodze "zesra" a może nawet przeszkadzać.
> 
> śmiem jednak wątpić czy to chcesz właśnie robić skoro piszesz na tę 
> grupę. 

Dokładnie. Pisząc o strumieniu miałem na myśli ilość danych a nie 
strumień danych jako taki.

padły sugestie o użycie typów złożonych do danych. to nie to samo
> co "strumienie". odpowiedź sobie na pytanie, czy potrzebujesz nadać 
> swoim danym strukturę złożoną albo czy czegoś brakuje typom prostym w 
> tym konkretnym zastosowaniu. wtedy będziesz wiedział, czy potrzebujesz 
> typów złożonych typu json, xml itp. powątpiewam, chociaż nie wykluczam, 
> że mógłbyś tak chcieć w konkretnym celu, np. w celu późniejszej wymiany 
> danych z innymi systemami jednym z popularnych standardów wymiany danych.
> 
> z tego co piszesz wnioskuję jednak, że wystarczą podstawowe typy proste. 
> prawdopodobnie potrzebujesz również stosunkowo prostej relacyjnej bazy 
> danych. sqllite by pewnie wystarczył z nawiązką. małe i sporo potrafi.


> skoro wspominasz o "pewności zapisu" to przydałoby się coś z obsługą 
> transakcji. ale pewnie świat się nie zawali gdy będzie nietransakcyjna 
> bo prawdopodobnie w swoich rozważaniach uwzględniasz, że awarie się 
> zdarzają i czujnik może się po prostu popsuć (i prawdopodobnie czujników 
> nie duplikujesz aby zapobiec utracie danych, co nie?) co będzie miało 
> finalny efekt taki sam jak transakcja, która się nie powiedzie - brak 
> danych.

To nie będzie system krytyczny. Dobrze aby działało jak najlepiej, ale 
jak nie zadziała to świat się nie zawali.


> summa summarum temat "co minutę do 50 wartości z 3 lokalizacji" IMHO nie 
> jest wart rozważań o partycjonowaniu, strumieniach, bazach nosql, typach 
> złożonych i na dodatek nowej ortografii :) zrób to najprościej bez 
> generowania zbędnych problemów: zbierz dane z czujnika, opakuj w 
> inserta, wrzuć do tabeli, zakomituj.

Na partycjonowanie tabel to rzeczywiście wydaje się za mało i efekt może 
być odwrotny od zamierzonego.

Jednak obecnie skłaniam się ku składowaniu surowych danych w MongoDB 
ewentualnie pójście w ekosystem Amazona: IoT Core / DynamoDB / Lambda. 
Następnie przetwarzaniu ich pod względem tego co będę chciał prezentować 
i zapisaniu tego w osobnej bazie.

Zastanawiam się czy to nie będzie czasem przekombinowane. Chociaż 1,5 
mln pomiarów a w nich 20 mln zmierzonych wartości rocznie to też nie 
jest mało i może warto.
Ewentualnie zamiast mierzyć co minute mogę zwiększyć odstęp pomiędzy 
pomiarami albo uśredniać wyniki w jakimś okresie i wysyłać średnie co 
zmniejszy wymagania co do systemu.

W dniu 2018-02-10 o 18:59, geos pisze:
> 
>> I tu właśnie, nawiązując do sąsiedniej Twojej odpowiedzi, PostgreSQL z 
>> typem, podkreślam: typem danych json, może być doskonałym środowiskiem 
>> do realizacji takiego hybrydowego rozwiązania.
> 
> a ma on jakąś przewagę nad xml-em (też obsługiwanym w bazie relacyjnej)?
Oczywiście, jest prostszy i bardziej zwarty, a co za tym idzie - te same 
informacje zajmują mniej miejsca.
Oczywiście to nie tak, że JSON to lepszy XML.
Nic a nic.

-- 
wloochacz

W dniu 2018-02-11 o 20:01, irq pisze:
> Nie jestem pewien, najlepiej byłoby przetestować. Tak na szybko - może oszczędzenie na liczbie wierszy? X wierszom par klucz: wartość jednego zestawu odczytów, w wersji z typami prostymi:
> 
> 'yyyy-mm-dd', 'temperatura', '-11.1'
> 'yyyy-mm-dd', 'cisnienie', '1011'
> ...
> 
> odpowiada jeden wiersz z typem json:
> 'yyyy-mm-dd', '{"temperatura":"-11.1","cisnienie":"1101",...}'

Prawda, ale mi chodziło o coś, co pomijacie;
Załóżmy że planujemy na dziś rejestrację informacji w postaci: 
timestamp, temperatura, ciśnienie.

Jutro jest potrzeba:
timestamp, temperatura, ciśnienie, So2, Co2

Pojutrze:
timestamp, temperatura, ciśnienie, So2, Co2, cos1, cos2,

A za tydzień zmienić/dodać całkowicie nowe relacje pomiędzy rejestracją 
wartości, a np. czujnikiem, adresem i Bóg wie czym jeszcze...
itd.
No i jak tu żyć z modelem relacyjnym?

Poza tym, bazy jak MongoDB to nie tylko JSON/BSON jako format danych, 
ale też (a może przede wszystkim) hierarchiczny model danych:
https://docs.mongodb.com/manual/applications/data-models-tree-structures/

A to daje okrutną przewagę nad podejściem relacyjnym sensu stricte, 
oczywiście w pewnych przypadkach.

I to nie jest tak, że jestem NoSQLowym neofitą. Nic a nic.
Raczej jestem relacyjnym betonem ;-), który zauważa pewne interesujące 
możliwości świata NoSQL.
Ale wszystko trzeba stosować z głową, a nie hurra-będzie-super :)

-- 
wloochacz

On 12.02.2018 19:12, wloochacz wrote:
> W dniu 2018-02-10 o 18:59, geos pisze:
>>
>>> I tu właśnie, nawiązując do sąsiedniej Twojej odpowiedzi, PostgreSQL
>>> z typem, podkreślam: typem danych json, może być doskonałym
>>> środowiskiem do realizacji takiego hybrydowego rozwiązania.
>>
>> a ma on jakąś przewagę nad xml-em (też obsługiwanym w bazie relacyjnej)?
> Oczywiście, jest prostszy i bardziej zwarty, a co za tym idzie - te same
> informacje zajmują mniej miejsca.
> Oczywiście to nie tak, że JSON to lepszy XML.
> Nic a nic.
>

ech, chyba tak nie do końca bo:

Binary XML storage. This is the default storage for Oracle XML Database. 
XML Typedata is stored in a post-parsed binary format specifically 
designed for XML data. Binary XML is compact, post-parsed, and XML 
schema-aware XML.

http://www.oracle.com/technetwork/database/database-technologies/xmldb/overview/xmldb-store-12cr1-2043451.pdf

oczywiście potrafi też tekstem. podczas gdy w postgresql:

So it appears that, for now at least, json is the same as a text 
datatype but with JSON validation. The text datatype's maximum size is 1GB.

https://stackoverflow.com/questions/12632871/size-limit-of-json-data-type-in-postgresql

jeśli json to ciągle typ znakowy to informacja jest przechowywana 1:1. 
liczba 123 to 3 bajty podczas gdy binarnie jeden bajt. nie wspominając o 
tym, że oracle do tagów XML pewnie zrobi odpowiednią tablicę-słownik 
zamieniając tagi tekstowe na niewielkie binarne podczas gdy tekstowo w 
postgresql to będzie po prostu ciągle jawny tekst.

sytuacja jest więc bardzo typu "to zależy".

pomijam już fakt, że ten json pojawił się w wątku na zasadzie "strzałów 
z nikąd". nie odniosłem wrażenia, że wynikałyby z wymagań wątkotwórcy. 
jak to leciało? "Entia non sunt multiplicanda praeter necessitatem". czy 
coś podobnego.

pozdrawiam,
geos

W dniu 2018-02-12 o 21:27, geos pisze:
> On 12.02.2018 19:12, wloochacz wrote:
>> W dniu 2018-02-10 o 18:59, geos pisze:
>>>
>>>> I tu właśnie, nawiązując do sąsiedniej Twojej odpowiedzi, PostgreSQL
>>>> z typem, podkreślam: typem danych json, może być doskonałym
>>>> środowiskiem do realizacji takiego hybrydowego rozwiązania.
>>>
>>> a ma on jakąś przewagę nad xml-em (też obsługiwanym w bazie relacyjnej)?
>> Oczywiście, jest prostszy i bardziej zwarty, a co za tym idzie - te same
>> informacje zajmują mniej miejsca.
>> Oczywiście to nie tak, że JSON to lepszy XML.
>> Nic a nic.
>>
> 
> ech, chyba tak nie do końca bo:
Oczywiście, że do końca.

> Binary XML storage. This is the default storage for Oracle XML Database. 
> XML Typedata is stored in a post-parsed binary format specifically 
> designed for XML data. Binary XML is compact, post-parsed, and XML 
> schema-aware XML.
> 
> http://www.oracle.com/technetwork/database/database-technologies/xmldb/overview/xmldb-store-12cr1-2043451.pdf 

Nie zauważyłeś jak pisałem o JSON/BSON?
BSON to odpowiednik binary XML dla JSON.

> oczywiście potrafi też tekstem. podczas gdy w postgresql:
> 
> So it appears that, for now at least, json is the same as a text 
> datatype but with JSON validation. The text datatype's maximum size is 1GB.
> 
> https://stackoverflow.com/questions/12632871/size-limit-of-json-data-type-in-postgresql 

A co ja napisałem, wcześniej?
Że z kozy się nie da konia zrobić, bo żadna baza relacyjna nie będzie 
fajna i miła jak baza NoSQL w zakresie przetwarzania danych nierelacyjnych.
Zatem nie napisałeś mi nic nowego...

> jeśli json to ciągle typ znakowy to informacja jest przechowywana 1:1. 
> liczba 123 to 3 bajty podczas gdy binarnie jeden bajt. nie wspominając o 
> tym, że oracle do tagów XML pewnie zrobi odpowiednią tablicę-słownik 
> zamieniając tagi tekstowe na niewielkie binarne podczas gdy tekstowo w 
> postgresql to będzie po prostu ciągle jawny tekst.
> 
> sytuacja jest więc bardzo typu "to zależy".
Oczywiście, prawie zawsze jest taka sytuacja.
Proponuję jednak doczytać wątek, ponieważ porównanie jak to "liczba 123 
to 3 bajty podczas gdy binarnie jeden bajt" to... hmmm... bez komentarza.
Gdybyś porównał takiego JSON z całym WIERSZEM w bazie relacyjnej, to 
jeszcze jako-tako.
Ale to powyżej?

Jednkaże takie porówaniania nie mają sensu, bo to są dwa zupełnie różne 
światy, które powstały z różnych wymagań.

> pomijam już fakt, że ten json pojawił się w wątku na zasadzie "strzałów 
> z nikąd". nie odniosłem wrażenia, że wynikałyby z wymagań wątkotwórcy. 
> jak to leciało? "Entia non sunt multiplicanda praeter necessitatem". czy 
> coś podobnego.
Nie JSON sensu stricte się tu pojawił, a baza NoSQL, której podstawą 
jest JSON/BSON.
Rozumiesz różnicę?
Bo mam wrażenie, że dla Ciebie takie MongoDB to storage dokumentów JSON. 
To prawda, ale będąca takim uproszeniem, jak stokrotkowa ortografia.
To znaczy, że zęby bolą jak się to czyta ;-)

-- 
wloochacz

On 13.02.2018 14:39, wloochacz wrote:
> W dniu 2018-02-12 o 21:27, geos pisze:
>> On 12.02.2018 19:12, wloochacz wrote:
>>> W dniu 2018-02-10 o 18:59, geos pisze:
>>>>
>>>>> I tu właśnie, nawiązując do sąsiedniej Twojej odpowiedzi, PostgreSQL
>>>>> z typem, podkreślam: typem danych json, może być doskonałym
>>>>> środowiskiem do realizacji takiego hybrydowego rozwiązania.
>>>>
>>>> a ma on jakąś przewagę nad xml-em (też obsługiwanym w bazie
>>>> relacyjnej)?
>>> Oczywiście, jest prostszy i bardziej zwarty, a co za tym idzie - te same
>>> informacje zajmują mniej miejsca.
>>> Oczywiście to nie tak, że JSON to lepszy XML.
>>> Nic a nic.
>>>
>> ech, chyba tak nie do końca bo:
> Oczywiście, że do końca.
>
>> Binary XML storage. This is the default storage for Oracle XML
>> Database. XML Typedata is stored in a post-parsed binary format
>> specifically designed for XML data. Binary XML is compact,
>> post-parsed, and XML schema-aware XML.
>>
>> http://www.oracle.com/technetwork/database/database-technologies/xmldb/overview/xmldb-store-12cr1-2043451.pdf
>
>
> Nie zauważyłeś jak pisałem o JSON/BSON?
> BSON to odpowiednik binary XML dla JSON.

nie, nie zauważyłem. odniosłem się do postu. zacytowałem go w całości i 
na niego odpowiedziałem. był tam json. nie śledziłem dokładnie całego 
wątku a być może nie pamiętałem co przeczytałem w postach innych 
odnosząc się do konkretnego.

>> oczywiście potrafi też tekstem. podczas gdy w postgresql:
>>
>> So it appears that, for now at least, json is the same as a text
>> datatype but with JSON validation. The text datatype's maximum size is
>> 1GB.
>>
>> https://stackoverflow.com/questions/12632871/size-limit-of-json-data-type-in-postgresql
>
> A co ja napisałem, wcześniej?
> Że z kozy się nie da konia zrobić, bo żadna baza relacyjna nie będzie
> fajna i miła jak baza NoSQL w zakresie przetwarzania danych nierelacyjnych.
> Zatem nie napisałeś mi nic nowego...

w ogóle nie pisałem o nosql ani nie miałem zamiaru pisać o nosql. 
napisałem o sposobie składowania. jeden cytat wziąłem z wątku 
poświęconym postgresowi.

> To znaczy, że zęby bolą jak się to czyta ;-)

piszesz w poście o json, odpowiadam na tego posta, poźniej mi sugerujesz 
bson. ok. odnosząc się do typu json, konkretnie do "zajętości" cytuję 
konkretną dokumentację/post z internetu dotyczącą metody składowania 
(ciągle odnosząc się do cytowanego postu) dla konkretnego typu. okazuje 
się, że źle odpowiedziałem bo chodziło o  nosql. masz wątpliwości co do 
składowania typu tekstowego, ale cytat z dokumentacji postgresa:

"The storage requirement for a short string (up to 126 bytes) is 1 byte 
plus the actual string, which includes the space padding in the case of 
character. Longer strings have 4 bytes of overhead instead of 1. Long 
strings are compressed by the system automatically, so the physical 
requirement on disk might be less."

odnosząc się pośrednio do pierwotnego problemu i mając na uwadze, że 
jeśli json to jest spora szansa, że w tych 126 bajtach komunikat z 
czujnika z pięcioma pomiarami się zmieści, np:

{"CZ":"kuchnia1","T":"-11.1","C":"1101","W":"98","X":"1546","Y":"abc"}

więc miałem podstawy aby poddać w wątpliwość to co poddałem. ale znowu 
pewnie czegoś nie zrozumiałem. więc tak sobie myślę, że chyba się nie 
rozumiemy na poziomie fundamentalnym. ze swojej strony przepraszam za 
złą interpretację.

pozdrawiam,
geos

W dniu 2018-02-13 o 15:10, geos pisze:
> On 13.02.2018 14:39, wloochacz wrote:
>> W dniu 2018-02-12 o 21:27, geos pisze:
>>> On 12.02.2018 19:12, wloochacz wrote:
>>>> W dniu 2018-02-10 o 18:59, geos pisze:
>>>>>
>>>>>> I tu właśnie, nawiązując do sąsiedniej Twojej odpowiedzi, PostgreSQL
>>>>>> z typem, podkreślam: typem danych json, może być doskonałym
>>>>>> środowiskiem do realizacji takiego hybrydowego rozwiązania.
>>>>>
>>>>> a ma on jakąś przewagę nad xml-em (też obsługiwanym w bazie
>>>>> relacyjnej)?
>>>> Oczywiście, jest prostszy i bardziej zwarty, a co za tym idzie - te 
>>>> same
>>>> informacje zajmują mniej miejsca.
>>>> Oczywiście to nie tak, że JSON to lepszy XML.
>>>> Nic a nic.
>>>>
>>> ech, chyba tak nie do końca bo:
>> Oczywiście, że do końca.
>>
>>> Binary XML storage. This is the default storage for Oracle XML
>>> Database. XML Typedata is stored in a post-parsed binary format
>>> specifically designed for XML data. Binary XML is compact,
>>> post-parsed, and XML schema-aware XML.
>>>
>>> http://www.oracle.com/technetwork/database/database-technologies/xmldb/overview/xmldb-store-12cr1-2043451.pdf 
>>>
>>
>>
>> Nie zauważyłeś jak pisałem o JSON/BSON?
>> BSON to odpowiednik binary XML dla JSON.
> 
> nie, nie zauważyłem. odniosłem się do postu. zacytowałem go w całości i 
> na niego odpowiedziałem. był tam json. nie śledziłem dokładnie całego 
> wątku a być może nie pamiętałem co przeczytałem w postach innych 
> odnosząc się do konkretnego.
To nie czytaj po łebkach!
Odpowiedziałem tylko i wyłącznie na ten kawałek:
"a ma on (tj. JSON) jakąś przewagę nad xml-em (też obsługiwanym w bazie 
relacyjnej)?"

Ale wcześniej nie pisałem o samym JSON - nic a nic.

A może Ty jakiegoś krzywego czytnika używasz (i nie widzisz poprawnie 
cytatów), co? :)

>>> oczywiście potrafi też tekstem. podczas gdy w postgresql:
>>>
>>> So it appears that, for now at least, json is the same as a text
>>> datatype but with JSON validation. The text datatype's maximum size is
>>> 1GB.
>>>
>>> https://stackoverflow.com/questions/12632871/size-limit-of-json-data-type-in-postgresql 
>>>
>>
>> A co ja napisałem, wcześniej?
>> Że z kozy się nie da konia zrobić, bo żadna baza relacyjna nie będzie
>> fajna i miła jak baza NoSQL w zakresie przetwarzania danych 
>> nierelacyjnych.
>> Zatem nie napisałeś mi nic nowego...
> 
> w ogóle nie pisałem o nosql ani nie miałem zamiaru pisać o nosql. 
> napisałem o sposobie składowania. jeden cytat wziąłem z wątku 
> poświęconym postgresowi.
Nie.
To Ty wyleciałeś z Postgresem do mnie, jako przykład przetwarzania w 
bazie relacyjnej.
I, OK - tylko wcześniej dokładnie do czegoś takiego się odniosłem. A 
konkretnie - to nie jest fajny pomysł, zwłaszcza jeśli są to dane 
operacyjne o sporej dynamice zmian/odczytów.

>> To znaczy, że zęby bolą jak się to czyta ;-)
> 
> piszesz w poście o json, odpowiadam na tego posta, poźniej mi sugerujesz 
> bson. ok. 
NIE!
Znowu po łebkach... I na dodatek wyciąłeś całe clue mojej wypowiedzi...

> odnosząc się do typu json, konkretnie do "zajętości" cytuję 
> konkretną dokumentację/post z internetu dotyczącą metody składowania 
> (ciągle odnosząc się do cytowanego postu) dla konkretnego typu. 
W jednej konkretnej implementacji (a nie, przepraszam - w dwóch 
implementacjach. PostgreSQL i Oracle) danej bazy relacyjnej.
I co z tego?

> okazuje 
> się, że źle odpowiedziałem bo chodziło o  nosql. masz wątpliwości co do 
> składowania typu tekstowego, ale cytat z dokumentacji postgresa:
Ja nie mam żadnych wątpliwości, po prostu wiem jak to działa.
I nie sugerowałem takiego rozwiązania dla bazy relacyjnej.

> "The storage requirement for a short string (up to 126 bytes) is 1 byte 
> plus the actual string, which includes the space padding in the case of 
> character. Longer strings have 4 bytes of overhead instead of 1. Long 
> strings are compressed by the system automatically, so the physical 
> requirement on disk might be less."
> 
> odnosząc się pośrednio do pierwotnego problemu i mając na uwadze, że 
> jeśli json to jest spora szansa, że w tych 126 bajtach komunikat z 
> czujnika z pięcioma pomiarami się zmieści, np:
> 
> {"CZ":"kuchnia1","T":"-11.1","C":"1101","W":"98","X":"1546","Y":"abc"}
> 
> więc miałem podstawy aby poddać w wątpliwość to co poddałem. ale znowu 
> pewnie czegoś nie zrozumiałem. więc tak sobie myślę, że chyba się nie 
> rozumiemy na poziomie fundamentalnym. ze swojej strony przepraszam za 
> złą interpretację.
Fakt, nie kumam co tu piszesz.
Jeszcze raz - mi się wydaje, że dla takich a nie innych wymagań baza 
NoSQL jest dobrym wyborem.
Podkreślam - baza NoSQL, a nie JSON w bazie relacyjnej.

-- 
wloochacz

W dniu 2018-02-10 o 18:48, Stokrotka pisze:
> Ale jak czytam te wypociny, tutaj, to zrozumiałam.
> W tym miejscu program był pszemyślany perfekcyjnie.
Tylko totalny dyletant może twierdzić, ze przemyślał cokolwiek perfekcyjnie.
Innymi słowy - poziom pewności siebie jest wprost proporcjonalny do 
niewiedzy.

-- 
wloochacz

>>>> Żaden magister nie robił by takiego podstawowego błędu, pszynajmniej
>>>> na pewno nie magister informatyki.
>>>> To tematyka z jednej strony niezwykle prosta.
>>>> Wydaje się , że wystarczy jeden , może dwa wykłady , lub ćwczenia, by 
>>>> zrozumieć wszystko ,
>>>> a klepana prymitywnie, do znudzenia cały pełny rok, może więcej.
>>>> Nie rozumiałam dlaczego tak długo była tłuczona tak prymitawna 
>>>> tematyka.
>>>> Ale jak czytam te wypociny, tutaj, to zrozumiałam.
>>>> W tym miejscu program był pszemyślany perfekcyjnie.
>>>>
>>> Nie dogadamy się. Może jesteś po AWF'ie. Na to wygląda. Nie masz pojęcia 
>>> o BD. Trudno.
>>>
>> Twoja bezczelnośc pszekracza pojęcie. Dziś idziesz do kosza.
>
> Mnie też tam wrzuć, ponieważ zgadzam się z przedmówcą.
> Moim zdaniem swoją "wiedzę" o BD opierasz na jakiś głupotach wyklikanych w 
> MS Access.

Już tam jesteś, od dawna, dawniej niż ten na M, tylko czasem pracuję w innej 
konfiguracji.
Na szczęście zawsze jesteś wyeksponowany na żułto, nie sam,
co u mnie onacza, "debil, rozrabiak, nie odpowiadać"
Ale czasem się zniżam.

-- 
(tekst bez: ó, ch, rz i -ii)
Ortografia to NAWYK, często nielogiczny, ktury ludzie ociężali umysłowo,
nażucają bezmyślnie następnym pokoleniom. ( ortografia . pev . pl ) 

W dniu 2018-02-15 o 11:54, Stokrotka pisze:
> 
>>>>> Żaden magister nie robił by takiego podstawowego błędu, pszynajmniej
>>>>> na pewno nie magister informatyki.
>>>>> To tematyka z jednej strony niezwykle prosta.
>>>>> Wydaje się , że wystarczy jeden , może dwa wykłady , lub ćwczenia, 
>>>>> by zrozumieć wszystko ,
>>>>> a klepana prymitywnie, do znudzenia cały pełny rok, może więcej.
>>>>> Nie rozumiałam dlaczego tak długo była tłuczona tak prymitawna 
>>>>> tematyka.
>>>>> Ale jak czytam te wypociny, tutaj, to zrozumiałam.
>>>>> W tym miejscu program był pszemyślany perfekcyjnie.
>>>>>
>>>> Nie dogadamy się. Może jesteś po AWF'ie. Na to wygląda. Nie masz 
>>>> pojęcia o BD. Trudno.
>>>>
>>> Twoja bezczelnośc pszekracza pojęcie. Dziś idziesz do kosza.
>>
>> Mnie też tam wrzuć, ponieważ zgadzam się z przedmówcą.
>> Moim zdaniem swoją "wiedzę" o BD opierasz na jakiś głupotach 
>> wyklikanych w MS Access.
> 
> Już tam jesteś, od dawna, dawniej niż ten na M, tylko czasem pracuję w 
> innej konfiguracji.
> Na szczęście zawsze jesteś wyeksponowany na żułto, nie sam,
> co u mnie onacza, "debil, rozrabiak, nie odpowiadać"
Dziękuje.
Zatem jestem pewnie w wyśmienitym towarzystwie :)

> Ale czasem się zniżam.
Sama widzisz, jesteś wszędzie taka konsekwentna jak z tą przyprawiająca 
o ból zębów ortografią...

-- 
wloochacz

On Thu, 15 Feb 2018 12:06:31 +0100, wloochacz wrote:

>>> Mnie też tam wrzuć, ponieważ zgadzam się z przedmówcą.
>>> Moim zdaniem swoją "wiedzę" o BD opierasz na jakiś głupotach 
>>> wyklikanych w MS Access.
>> 
>> Już tam jesteś, od dawna, dawniej niż ten na M, tylko czasem pracuję w 
>> innej konfiguracji.
>> Na szczęście zawsze jesteś wyeksponowany na żułto, nie sam,
>> co u mnie onacza, "debil, rozrabiak, nie odpowiadać"
> Dziękuje.
> Zatem jestem pewnie w wyśmienitym towarzystwie :)
> 
>> Ale czasem się zniżam.
> Sama widzisz, jesteś wszędzie taka konsekwentna jak z tą przyprawiająca 
> o ból zębów ortografią...

A kto tu wyżej napisał "jakiś" zamiast "jakichś"? ;-)

-- 
pozdrawiam
Roman Tyczka

On Thu, 15 Feb 2018 11:37:06 +0100, wloochacz wrote:

>> Ale jak czytam te wypociny, tutaj, to zrozumiałam.
>> W tym miejscu program był pszemyślany perfekcyjnie.
> Tylko totalny dyletant może twierdzić, ze przemyślał cokolwiek perfekcyjnie.
> Innymi słowy - poziom pewności siebie jest wprost proporcjonalny do 
> niewiedzy.

Wooow... przeczytaj to co napisałeś i dokonaj autorefleksji! :-D

-- 
pozdrawiam
Roman Tyczka

W dniu 2018-02-15 o 12:32, Roman Tyczka pisze:
> On Thu, 15 Feb 2018 12:06:31 +0100, wloochacz wrote:
> 
>>>> Mnie też tam wrzuć, ponieważ zgadzam się z przedmówcą.
>>>> Moim zdaniem swoją "wiedzę" o BD opierasz na jakiś głupotach
>>>> wyklikanych w MS Access.
>>>
>>> Już tam jesteś, od dawna, dawniej niż ten na M, tylko czasem pracuję w
>>> innej konfiguracji.
>>> Na szczęście zawsze jesteś wyeksponowany na żułto, nie sam,
>>> co u mnie onacza, "debil, rozrabiak, nie odpowiadać"
>> Dziękuje.
>> Zatem jestem pewnie w wyśmienitym towarzystwie :)
>>
>>> Ale czasem się zniżam.
>> Sama widzisz, jesteś wszędzie taka konsekwentna jak z tą przyprawiająca
>> o ból zębów ortografią...
> 
> A kto tu wyżej napisał "jakiś" zamiast "jakichś"? ;-)
Pewnie jakiś żułty typ...

-- 
wloochacz

W dniu 2018-02-15 o 12:32, Roman Tyczka pisze:
> On Thu, 15 Feb 2018 11:37:06 +0100, wloochacz wrote:
> 
>>> Ale jak czytam te wypociny, tutaj, to zrozumiałam.
>>> W tym miejscu program był pszemyślany perfekcyjnie.
>> Tylko totalny dyletant może twierdzić, ze przemyślał cokolwiek perfekcyjnie.
>> Innymi słowy - poziom pewności siebie jest wprost proporcjonalny do
>> niewiedzy.
> 
> Wooow... przeczytaj to co napisałeś i dokonaj autorefleksji! :-D

Jeśli masz jakiś konkretny zarzut do mnie, to po prostu napisz konkretnie.
Chętnie poszerzę swoje obszary świadomej niewiedzy celem znalezienia 
drogi do oświecenia.

Poważnie piszę, ponieważ zawsze uważam, że można zrobić coś lepiej. 
Jednakże nie zawsze opłaca się to robić, ale zawsze warto to wiedzieć.

-- 
wloochacz