Granica między logiką po stronie javy, a po stronie bazy danych

Cześć. Już kiedyś się nad tym zastanawiałem, ale teraz temat wrócił ze zdwojoną siłą.

Pracuję obecne w robocie z widokiem, którego sqlka ma 1000 linijek. Zawiera 10 unionów z innych tabel/widoków i dodatkowo w warunkach ma when/casy i jakieś inne wyliczenia.
Ogólnie temat polega na tym, że mamy ten widok zoptymalizować bo zapytania trwają niekiedy kilka sekund (ponad 150 mln rekordów). Samo analizowanie logiki tego widoku pewnie zajmie mi 150 lat, ale nie o to chodzi.

Bardziej zastanawia mnie gdzie leży granica umieszczania logiki. Wiem, że jednak logika powinna być w javie, ale po coś też robi się te widoki, żeby ukryć pod spodem joiny itd.

Czy są jakieś zasady mówiąca, że dana logika powinna być wyniesiona z DB do kodu ?

Zdr.

Logiki po stronie bazy danych trzeba za wszelką cenę unikać, ponieważ jest trudno testowalna i trudniejsza w utrzymaniu. Dlatego bd ograniczam to tabel (no może widoków też)

Pytanie, gdzie jest granica między logiką a "zwykłym" zapytaniem z parametrami? Bo czasami jeden dodatkowy warunek przy SELECT, albo jakaś inna prosta operacja wykonana w ramach SQL, może oszczędzić wiele mielenia i kombinowania po stronie klienta.

Ja uznaję za głupie obliczanie w SQL sum narastająco, dopełnianie pól spacjami (formatowanie). Te rzeczy powinny być na kliencie (w kodzie Javy / silniku raportowym).
Z kolei wszystko co może dać nadzieję na wydajność bazy, w tej bazie powinno być. Czasem nawet bazę lekko de-normalizując.

Pytanie, jakie sobie stawiam, dobry wątek aby je zgłosić. Po jaką cholerę prowadzić projekt w JPA, jeśli olbrzymi procent odczytów, a co gorsza zapisów jest w natywnych kwerendach.

Hej,
ze swojego niewielkiego doświadczenia bazodanowego, wydaje mi się, że najlepiej zrzucić z bazy potrzebne dane (w kawałkach), a następnie je obrabiać np. w Excelu. Rzadko się zdarzy, że będą potrzebne Ci wszystkie dane, jeżeli tak, to wtedy robisz zapytanie w bazie. Natomiast jeżeli zależy Ci na profesjonalnym ogarnięciu bazy, pomyśl (lub pomyślcie) o przeniesieniu bazy na rozwiązania chmurowe (w systemie Hadoop). Jest sporo opcji, samemu można postawić klaster, nie trzeba wiele jednostek, a w sumie można postawić klaster na jednym komputerze, i podpiąć się pod klaster chmurowy w miarę potrzeb. Można też "postawić" (w sensie wynająć) serwer w chmurze, np. na Azure, na Clouderze, tylko nie wiem jak jest z Bezpieczeństwem Danych jeżeli chodzi o Firmę. Musiałbyś pogadać z jakimś gościem/kobietą, który/a się tym zajmuje :) Aha, jeszcze jeden pomysł (doraźny): spod Javy można, z tego co wiem, dobrać się do Sparka (narzędzie do Analizy i Obróbki danych), tu też jest parę możliwości :)

Zależy z jakich baz korzystasz. Wiele baz ma zoptymalizowane operacje join i union. Niektórzy jednak pozbywają się joinów i używają tylko selectów, a wyciągane dane łączą w pamięci w jakimś języku programowania. Ogólnie rzecz biorąc operacje w pamięci są najszybsze. Na Twoim miejscu spróbował zrzucić do niej dane (czy to do cache głównej bazy czy to w ogóle do jakiejś bazy in-memory. (SQLite z opcją memory, redis, whitedb). Odczyt danych będzie o wiele szybszy.

Co się przeszuka szybciej

1 instancja db 150mln

czy 3 instancje 50mln?

siloam napisał(a):

Zależy z jakich baz korzystasz. Wiele baz ma zoptymalizowane operacje join i union. Niektórzy jednak pozbywają się joinów i używają tylko selectów, a wyciągane dane łączą w pamięci w jakimś języku programowania. Ogólnie rzecz biorąc operacje w pamięci są najszybsze. Na Twoim miejscu spróbował zrzucić do niej dane (czy to do cache głównej bazy czy to w ogóle do jakiejś bazy in-memory. (SQLite z opcją memory, redis, whitedb). Odczyt danych będzie o wiele szybszy.

No to wszystko bardzo zależy. Bo np co będzie lepszą metodą na posortowanie - mielenie całej kolekcji obiektów w javie, czy dodanie ORDER BY na kolumnie która ma index?

Alternatywą dla skomplikowanego widoku z case'ami byłoby wprowadzenie jakichś flag. Byłyby one redundantne (nadmiarowa informacja), trudne w utrzymaniu, ale pozwalałyby pozbawić bazę danych tej logiki.

Skrajnym przypadkiem są bazy typu Cassandra, gdzie tabele projektuje się pod konkretny ekran. Nadmiarowość jest olbrzymia, ale dzięki temu wydobycie danych jest błyskawiczne. W sumie, kto zabroni zrobić tak na relacyjnej bazie?