🚀 go-pugleaf

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.