[Hauleth]

@Khaine: to bierzesz sobie TimescaleDB lub jakąś DB kolumnową i lecisz. Zawsze możesz mieć nawet 2 DB, i używać tej, która ma w danym momencie większy sens.

[Khaine]

@Hauleth: TimescaleDB to jakiś extension do PostgreSQL?

[Hauleth]

@Khaine: Tak

[Khaine]

@Hauleth: Czyli można dopiąć do bazy PGSQL drugą taką, która będzie sobie sama robić hurtownię agregowaną czasowo? Hmm...

[ksiak]

@Hauleth: tak, tylko tutaj zachodzi problematyka językowa. Relacja to jest owszem tabela, ale zazwyczaj mówiąc relacja mamy na myśli właśnie te jak to nazwałeś "JOINY" czyli związki co wprowadza jeszcze większe zamieszanie o czym można przeczytać w tym artykule.

Samo określenie RELACJA w nomenklaturze języka polskiego, może być trochę tutaj mylące. W końcu RELACJA i ZWIĄZEK to synonimy a jak widać dotyczą dwóch zupełnie różnych światów RELACJA=TABELA a ZWIĄZEK to

[Khaine]

@ksiak: @Hauleth: No generalnie można mieć bazę SQL "bez relacji", wystarczy że nie ma żadnych kluczy obcych pozakładanych. Wtedy nie ma dużej różnicy wobec NoSQLowego wiadra, bo i tak trzeba robić selecty z wielu tabel i łączyć przez WHERE.

[Hauleth]

@ksiak: tyle, że JOIN nie jest relacją, tylko operacją w algebrze relacji. Tutaj dane wewnątrz tabeli są w "relacji", bo są ze sobą silnie związane (wewnątrz wierszy i kolumn). "Relacje" jako JOINy istnieją tylko na wysokim poziomie dla "człowieka". Więc to jest problem z tłumaczeniem algebry a nie nomenklaturą, bo JOIN nie oznacza ani "relacji" ani "związku".

[Hauleth]

@Khaine: nawet bez kluczy obcych masz relacje, bo TABELA jest RELACJĄ. JOINy to nie relacje, tylko operacje na relacjach, niczym dodawanie przy liczbach.

[Khaine]

@Hauleth: TimescaleDB komercyjnie nie jest płatne czasem?

[ProfesorChleb]

@Khaine: A moze data warehouse skoro potrzebujecie agregacji.

[Hauleth]

@Khaine: Nie, wersja OpenSource jest darmowa dla wszystkich, którzy chcą.

[Khaine]

@Hauleth: W sumie to się straci tylko agregację w trybie ciągłym, ale to chyba akurat wiele nie zmieni, bo dane są potrzebne na żądanie z nie wiadomo jakiego okresu i zawsze trzeba będzie liczyć w locie, interpolacja i tak nie jest nam potrzebna raczej. Jak już to się po prostu dopisze samemu ( ͡° ͜ʖ ͡°)

[Khaine]

@Hauleth: Swoją drogą trochę mnie zastanawia skąd tyle głosów za agregacjami w backendzie a nikt z tych ludzi się nie wypowiedział czemu akurat tak, kiedy przypadek jest raczej nie za bardzo po myśli liczenia w backendzie? ¯\_(ツ)_/¯ Brzmi jak "liczyłbym w backendzie z lenistwa, bo mi się nie chce pisać procedur i nie mówię czemu akurat tak, bo też mi się nie chce" xD

[kefaise]

@Khaine: Polecam architekturę Lambda. Może nie użyjecie, ale moim zdaniem warto znać.

[M.....v]

@Khaine: Development backendu jest szybszy.
Często nie ma tylu danych, te milisekundy opóźnienia na jednej operacji nie mają znaczenia, za to czas programisty jest drogi.

[ksiak]

@Hauleth: jak widzisz, podałem Ci jeden z przykładowych artykułów w którym ładnie wyjaśniono problematykę nazewnictwa. Teraz Ty próbujesz to dalej tłumaczyć co wykracza już całkowicie poza pytanie OP.

[Hauleth]

@ksiak: Problem w tym, że ten artykuł też miesza pojęcia z algebry relacji (relacje) z pojęciami z samej implementacji w DB (klucze) przez co powoduje jeszcze większe zamieszanie. Nic nie stoi na przeszkodzie, by mieć JOINy w nierelacyjnych DB (np. w CouchBase mamy JOINy).

[jaggi]

@Khaine: wszystko zależy od tego co dokładniej ma się dziać. baza jest bezpieczniejsza, bo nie będziesz pobierać zbędnych danych. Jak źle napiszesz backend, to taka agregacja może się skończyć 15 zagnieżdżonymi pętlami, które będą się wykonywać cholernie długo. Baza jakoś sobie zoptymalizuje, C# będzie wykonywał dokładnie co mu napiszesz.
Zastanów się jak dobrze u was z optymalizacją takich rzeczy w kodzie. Jeżeli np, często zdarza się że wewnątrz jednej pętli

[Khaine]

Jeśli chodzi o backend, zamierzasz używać jakiegoś ORM-a

@jaggi: Co najwyżej Dappera.