🚀 go-pugleaf

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.