Przetwarzanie danych po stronie bazy, czy w aplikacji?

Odpowiedz Nowy wątek
2019-07-31 20:24
0

Hej,

zacząłem się zastanawiać nad pewnym tematem. Otóż gdzie lepiej przetwarzać dane pobierane z bazy? Zauważyłem u siebie tendencję do wyciągania danych z bazy jakimś prostym zapytaniem, filtrując raczej po jednym, czy dwóch kryteriach, a następnie filtruję, zliczam, czy cokolwiek innego np. wrzucając listę w stream (Java) i operując na danych w aplikacji. Zacząłem się jednak zastanawiać co jest dobrą praktyką w takim przypadku. Czy lepiej napisać natywnie jakieś bardziej skomplikowane zapytanie do bazy i starać się jak najdokładniej przefiltrować dane po stronie DB do postaci najbliższej takiej, jaka mi jest potrzebna, czy własnie lepiej zrzucać tę odpowiedzialność na kod aplikacji. Jak to wygląda u was? Co jest lepszą praktyką?

Pozostało 580 znaków

2019-08-01 10:03
1

Wiem, że przykład banalny, ale ja bym mimo wszystko już sumował po stronie aplikacji, bo za chwile dojdą Ci jakieś przypadki, wyjątki itp. Dodatkowo szybciej (w pamięci) przetestujesz taką logikę jeśli jest po stronie aplikacji.


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.

Pozostało 580 znaków

2019-08-01 10:10
3

Wszystko, co możesz, robisz po stronie SQLa. Dlatego że jest wydajniej, mniej przepychasz do klienta, serwera aplikacyjnego. I to baza sobie lepiej poradzi z tym niż jakiś nawet wypasiony algorytm po stronie klienta, bo np. nie ma statystyki, indeksy itp.

edytowany 1x, ostatnio: Tomek Pycia, 2019-08-01 10:19

Pozostało 580 znaków

2019-08-01 10:19
4
Shalom napisał(a):

Jeśli chodzi o filtrowanie to jak najbardziej lepiej po stronie bazy. Ale ABSOLUTNIE nie wrzucać tam logiki i robić jakichś procedur, bo ugryzie cię to w dupę i to bardzo mocno. Testowalność takich rzeczy jest zerowa, plus vendor lock over 9000.

W bazach robie już kilkanaście lat i przez ten czas nie widziałem aplikacji "vendor free" ponad sklep internetowy. I to tak obsługiwał tylko PostgreSQL i MySQL. Jak chcesz zrobić wydajną aplikacje, która działa wydajnie przy milionach rekordów to raczej musisz zacząć wykorzystywać funkcjonaliści zależne od konkretnego dostawcy. Spotkałem się z próbami zrobienia taki aplikacji które z czasem spełzły na niczym z tego względu, że wspieranie kilku vendorów jest strasznie kosztowne — programiści muszą być świadomi i wyedukowani, że wszystko musi działać na różnych bazach, kilka razy więcej testów (na każdego vendora osobno ) itp itd. Tak czy inaczej, kończy się na tym, że wygrywa wiodący dostawca, który dostarcza najlepsze rozwiązanie dla danego typu danych i logiki.

Nom nawet Gitlab ostatnio zrezygnował z MySQL - student pro 2019-08-06 01:33

Pozostało 580 znaków

2019-08-01 10:23
0

Dobierasz implementację pod konkretny problem.

Baza poradzi sobie z dużymi zbiorami danych (łączenia, filtrowanie, agregacje itd.), ale ciężko będzie w czystym SQLu mieć logikę, która będzie przechodzić po jakichś złożonych strukturach (np. grafach cyklicznych) i coś tam wyliczać.

W drugą stronę, pamięć będzie ograniczać max. zbiór danych jakich jesteś w miarę bezboleśnie przetworzyć po stronie aplikacji (rozwiązania typu spark, zakładają, że umiesz podzielić duży zbiór danych na małe, mieszczące się w pamięci i operować na małych, ale jaki sens jest implementowanie własnego partycjonowania danych, nested loopa czy hash joina w oparciu sparka, jeśli baza sobie z tym radzi bez problemu?)

Pozostało 580 znaków

2019-08-01 10:37
6
Belka napisał(a):
Shalom napisał(a):

Jeśli chodzi o filtrowanie to jak najbardziej lepiej po stronie bazy. Ale ABSOLUTNIE nie wrzucać tam logiki i robić jakichś procedur, bo ugryzie cię to w dupę i to bardzo mocno. Testowalność takich rzeczy jest zerowa, plus vendor lock over 9000.

Czyli - biorąc po lupę bardzo prosty przykład - lepiej po stronie bazy wyszukać wszystkie wypłaty danego pracownika, ale np. zsumować je wszystkie lepiej po stronie aplikacji? Bo w sumie takie sumowanie to już jest jakaś (biedna, bo biedna ale zawsze jakaś) logika. Dobrze rozumiem?

To nie jest logika tylko CRUDowe zapytanie


SELECT sum(payment) FROM payment WHERE payment.user_id = 1985; 

Logika może być wyliczanie np. opłaty za czas na siłce w zależności od sposobu zapłaty (jesli karnet to 0, jeśli multisport to 0 za 1 h a później 10h za każdą)


Nie pomagam przez PM. Pytania zadaje się na forum.
edytowany 3x, ostatnio: scibi92, 2019-08-01 11:25

Pozostało 580 znaków

2019-08-01 16:17
6

Póki coś się da zapisać jednym query to jest ok. Ale jak zaczynasz klepać procedurę w bazie to zalecam rozpędzić się i walnąć głową w ścianę. Testowalność jest zerowa, wsparcie IDE zerowe, debugowalność zerowa. Może pewne rzeczy nawet byłby szybsze, tylko to trochę jak argument żeby klepać jakiś algorytm w asemblerze. Może będzie milisekundę szybciej, ale niestety write-only i za jakiś czas ten fragment będzie obłożony // here be dragons, magic, do not touch


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
Dramatyzujesz. Można pisać unit testy po stronie bazy. Kiedyś jak utrzymywałem taki system to mieliśmy taki magiczny przycisk który z kilenta pozwalał debugować skrypt po stronie bazy danych. - Tomek Pycia 2019-08-01 16:21
Chciałbym to zobaczyć ;) - Shalom 2019-08-01 16:23
Niestety teraz nie jestem ci tego wstanie pokazać. Narzędzie frontowe firma robiła sobie sama (oparte na winapi). Logika była oparta na Oracle. Akurat pracowałem tam w serwisie to się odebugowałem tego kodu tyle, że masakra. - Tomek Pycia 2019-08-01 16:27
I jeszcze dodam, że cała logika była w bazie. Jak masz trochę tu trochę tam, to wówczas jest to utrudnione. - Tomek Pycia 2019-08-01 16:29

Pozostało 580 znaków

2019-08-01 17:18
0

Obecnie odchodzi się od procedur po stronie bazy bo zmieniła się typowa architektura z monolitów na mniejsze serwisy. Kolejna przyczyna to łatwiejsza możliwość pozyskania programisty javy niż baz danych - po co płacić dwóm osobom jak można jednej :) . W większości przypadków wydajność i tak nie ma znaczenia do momentu, aż ktoś mocno nie skopie zaprojektowanej funkcjonalności, albo dotrzemy do limitu maszyny, która pierwotnie została kupiona z dużym zapasem mocy.

edytowany 1x, ostatnio: ralf, 2019-08-01 17:19
Pokaż pozostałe 9 komentarzy
"nie widziałem jeszcze typowego biznesowego działającego systemu opartego na procedurach" zdecyduj się, tylko nie pisz proszę, że erp albo inny system nie jest "biznesowy" - ralf 2019-08-06 10:49
Ja "spotkałem" taką znaną firmę pośrednictwa finansowego na rozmowie rekrutacyjnej. Wszystko oparte o Oracle. - student pro 2019-08-06 11:20
Przez "oparty" rozumiem, że wszystkie/większość operacji, łącznie z typowym crudem używa procedur, a nie że procedury użyte są tam, gdzie to niezbędne. - somekind 2019-08-06 12:35
Tak, to miałem na myśli. - student pro 2019-08-06 14:00
@student pro: ja odpisywałem do @ralf, Ty się pojawiłeś znienacka w międzyczasie. ;) - somekind 2019-08-06 14:16

Pozostało 580 znaków

2019-08-01 17:21
4

@Shalom, to się da zrobić. Np. w Visual Studio da się debugować SQL krok po kroku, pisać "unit testy" do procedur składowanych (są takie szablony projektów) i nawet się da odpalać to w continous integration. Tylko nie wiem po co. :P
Kiedyś nawet byłem w projekcie, w którym takie rzeczy stosowano, w życiu tak szybko nie uciekałem.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-08-01 19:29
xy
3

Mówienie, że coś jest złą praktyką (procedury w bazie), bo się nie zna lub słabo zna języki i narzędzia, które to umożliwiają, oraz uznaje je za mało modne i mało "ninja" w CV, to jest w sumie świetna odpowiedź dla gościa, który dofiltrowuje sobie dane w Javie (czy czym tam), bo nie zdążył jeszcze douczyć się, jak zapisać warunki w SQL. ;)
Ja bym poszedł dalej - programowanie jest złą praktyką, jak się nie umie programować. Co tam mało debugowalne, testowalne, utrzymywalne. Nie bójmy się powiedzieć, po prostu męczące, upierdliwe i kiedyś się znudzi. ;P

Pozostało 580 znaków

2019-08-01 20:01
2

@xy ano masz racje, to na pewno dlatego. I to zupełny przypadek że odchodzi się od wielkich baz danych na rzecz polyglot persistence i że już od dawna odchodzi się od klepania logiki w bazie ;) Na przykład ci ludzie:

ewidentnie nie mają pojęcia co robią. Brakuje im tam ciebie! xD


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
Pokaż pozostałe 28 komentarzy
Tu w ogóle należałoby chyba zrobić krok wstecz i zacząć dyskusję na nowo od pytania: "Czemu zmieniać FV w bazie, i ile lat za to grozi?". - somekind 2019-08-05 18:30
@somekind: To jest faktura FV i zaufaj mi - nic nikomu za to nie grozi za korektę pozycji. Zbierane są (nie wystawiane) tylko w celach statystycznych :) A czemu są zmieniane w bazie? Bo musiałbym po jej usunięciu prosić hurtownię o ponowne jej wysłanie. A czasem hurtownie takiej możliwości nie mają. Mogą wysłać paczkę z całego dnia, ale nie poszczególną FV. - Marcin.Miga 2019-08-05 23:06
Ok, rozumiem. Czyli masz jakiś specyficzny przypadek, w którym musisz ręcznie poprawiać błędy w importowanych danych. Szczęściarz ze mnie, że z nikim przez zepsute paczki się nie integruję. :) - somekind 2019-08-06 01:21
@somekind: tak ostatnio widzę, że zacząłeś doceniać swoje systemy, czyli może jakieś ciasto dla archytektów? - WeiXiao 2019-08-06 01:43
To nie jest zależne od architektów tylko od biznesu. Ale jak masz arszenik na zbyciu, to nie ma sprawy, ciasto dla architektów chętnie upiekę. - somekind 2019-08-06 01:45

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0