🚀 go-pugleaf

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.