Logika aplikacji głównie w bazie danych

Ten wątek to dowód na to, że niektórym ludziom na tym forum brakuje pokory. Jeden przykład skopanej architektury przytoczony przez @woolfik stał się przyczynkiem do jechania po "bazodanowcach". Dowiedzieliśmy się, że osoby które implementują logikę biznesową w bazie danych utknęły mentalnie w latach 80-tych, a szkolenia z baz danych organizuje Szatan, żeby siać zamęt na kuli ziemskiej. Po lekturze można odnieść wrażenie, że każdy kto nieco bardziej zna się na bazach danych jest w rzeczywistości debilem, który zna bazy danych, ponieważ nie potrafił nauczyć się nic innego. W dodatku nauczył się tych baz danych źle i teraz implementuje triggery, które się wzajemnie zakleszczają, radośnie do tego klaszcząc. Przykład z read uncommitted też mi się bardzo podobał, trzeba być specjalistą od Javy żeby wiedzieć co to znaczy, bo my nie wiemy.

Ten cytat: "na ludzi znajacych SQLa patrzy sie jak na dziwakow z poprzedniej epoki" przepełnił już chyba te szambo i wątek można zamknąć. W ogóle cały dział najlepiej zamknąć, żeby nikt nigdy więcej nie popełniał tej zbrodni o której mowa.

Panczo napisał(a):

Jednak z trudnością SQL to chyba za duży skrót myślowy, sama składnia jest banalna, trudne to jest opanowanie jego używania, zaczynając od poznania danych, a na specyficznych "mykach" silnika kończąc.

Składnia jest banalna, ale koncepcje już nie, a pilnowanie porządku w kodzie SQL to już w ogóle.

Pisząc przykłady skrajne chciałem uzmysłowić, ze są rozwiązania, które przeginają w każdą stronę i jak zaznaczyłem każda skrajność nie jest dobra

Tak, trzeba dobierać narzędzia do celu, a nie całe życie używać swojej drogi, bo jest "swojsza". Tylko aby móc wybrać trzeba przynajmniej wiedzieć, że można wybrać.

Z tego wynika, że my się zgadzamy ;)

W takim razie zgodnie z rozumowaniem najlepszych architektów tego wątku nie znasz SQL. ;)

To absolutnie konieczne jest różnie rozumiane i zależnie od projektu do którego trafiamy to absolutnie jest w innym miejscu

Jasne, inaczej do tego się podchodzi gdy mamy stałą strukturę bazy, inaczej gdy się często zmienia, wszystko też zależy od nacisku na wydajność i od fazy projektu (inaczej podczas wytwarzania, inaczej podczas utrzymywania, gdy już struktura jest stabilna).
A przynajmniej powinno tak być, bo w praktyce jest tak, że jak osoba decyzyjna jest wychowana w duchu "baza danych jest centrum systemu", no to jest jak jest.

Haskell napisał(a):

każdy kto nieco bardziej zna się na bazach danych jest w rzeczywistości debilem, który zna bazy danych

Jak ktoś się naprawdę zna się na bazach danych, to wie do czego służą i co można lepiej zrobić w bazie, a co w aplikacji.

Logiki po stronie baz danych staram się unikać, ale jeśli mam zrobić np. cztery ciężkie zapytania zwracające masę danych z których wyciągamy jakąś względnie niedużą część wspólną to nie mam problemu z "róbmy to w PL/SQLu".

Już kiedyś pisałem - co sprawdza się w aplikacjach biznesowych (ban na logikę w bazach danych) nie musi się sprawdzać w systemach centralnych.

Pytanie czy stosujecie takie podejście i czy stosowalibyście gdybyście mogli, a jeśli tak, to dlaczego?

chyba jedyna logika w bazie danych ktora ma dla mnie sens to cos co jest zwiazane z ochrona spojnosci danych (np klucze i inne constrainty), wydajnoscia zapytan (np. indeksy, widoki) i enkapsulacja (np uprawnienia czy widoki). rzeczy takie jak procedury, funkcje, triggery itp zostawilabym db adminowi zeby sobie robil z nich uzytek (jesli mu do czegos to potrzebne).

Drugie pytanie: jak wytłumaczyć komuś kto ma kilka aplikacji na jednej bazie danych (co raczej nie jest czymś nadzwyczajnym) żeby nie implementował logiki w bazie?

mysle ze komus kto robi takie cos ciezko bedzie to wytlumaczyc technicznie (z oczywistych powodow, tzn gdyby argumenty techniczne mialy dla niego wartosc to nie byloby problemu), dlatego lepiej wytoczyc ciezka artylerie trafiajaca do "managerow":

• ciezko znalezc na rynku pl/sql, t-sql (...) developerow
• w wielu przypadkach pisanie w *sql jest wolniejsze (jest to rozwlekle i czesto trzeba robic mase obejsc bo sql jest zbyt prymitywny) niz w normalnym jezyku i przez to bardziej kosztowne
• kod jest trzymany w bazie, byle kto moze zobaczyc, zmienic i zepsuc (no jasne ze mozna zapobiegac ale kontrola jest czesto duzo trudniejsza niz w wypadku buildow/binarek), jak sie wykaszani to wszystkie zalezne appki zepsute

A co sadzicie o tym?

DisQ napisał(a):

...

Jakikolwiek nowy feature który wymagał interakcji z bazą danych, nie daj Boże insert, to była mordęga. Skutkowalo to tym, że trzeba było się upewnić, że dana interakcja nie wysadzi żadnej niewidocznej z poziomu aplikacji logiki (lub nie wsadzi danych, które wysadza inna aplikacje o której nawet się nie słyszało :)). To znowu wymuszało przekopywanie się przez nieudokumentowane w żaden sposób 5000 linijkowe pakiety, a niech w tym wszystkim znajdzie się bug - tydzien analizy... Oczywiście testów brak, debugowanie też znacznie bardziej utrudnione niż w przypadku zwykłej apki.

Ogólnie na papierze pomysł wygląda w miarę, a w praktyce w ogóle się nie sprawdza (opinia oparta jedynie o moje własne doświadczenia, może gdzieś istnieje projekt z taką architekturą w którym praca to przyjemność... Może...)

Jeśli spojrzysz na pakiet jako analogię mikroserwisu, to może się okazać, że powyższe mordęgi nie zależą od tego czy mamy kod proceduralny w bazie czy inaczej w "appce". Zmiana w jednej appce może wybuchnąć cały flow integracyjny (albo i kilka). Z moich obserwacji wynika, że brak dokumentacji jest niezależny od technologii :-)

jarekr000000 napisał(a):

vpiotr napisał(a):

Drugie pytanie: jak wytłumaczyć komuś kto ma kilka aplikacji na jednej bazie danych (co raczej nie jest czymś nadzwyczajnym) żeby nie implementował logiki w bazie?

Kilka aplikacji na jednej bazie danych. Bardziej nie da się już zepsuć...

@jarekr000000: Nie można takich rzeczy pisać młodym ludziom, bo się nauczą, że to coś złego. To tak jakby pisać, że kolokacja nie ma sensu, albo że kilka aplikacji na jednym serwerze to zepsute. Szczególnie bez zdefiniowania czym jest owa "jedna baza danych" ;)

Nawet jeśli logika będzie poza bazą danych, to możliwość zmiany tych samych danych przez 2 różne aplikacje (w sensie logicznym, a nie fizyczne instancje), moim zdaniem, już jest bardziej zepsute niż wiele aplikacji korzystających z tego samego serwera bazodanowego i zmieniającego rozłączne dane na różne sposoby (część via PL/SQL, część przez coś innego).

Offtopic:
Jeśli ktoś finansuje aktywności R&D i ma głębokie kieszenie, to może zagwarantować warunki, w których można się skupiać na idealnych rozwiązaniach (kto by nie chciał takiej idealnej roboty, żeby tworzyć doskonałe rozwiązania i poświęcić jeszcze tylko dodatkowy rok na dowiezienie jeszcze lepszego rozwiązania ;-) ) W praktyce jednak inwestorzy (biznes) zakładają jakąś stopę zwrotu (oszczędność lub zysk w określonym horyzoncie czasowym) z inwestycji w automatyzację i szybsze/tańsze rozwiązanie będzie po prostu preferowane. Nawet doczekało się to dedykowanego określenia: Homo oeconomicus. Jeśli ktoś nie zakłada zwrotu w inwestycję, to może optymalizować jakość (pewnie dlatego rozwiązania z tagiem "Open Source" bywają lepsze w wielu obszarach).

@vpiotr: "jak wytłumaczyć komuś kto ma kilka aplikacji na jednej bazie danych (co raczej nie jest czymś nadzwyczajnym) żeby nie implementował logiki w bazie?" - wydaje mi się, że trzeba rozmawiać z tym, kto faktycznie decyduje i za to płaci i mówić do tych osób językiem, który są w stanie zrozumieć :-)

Jak dla mnie można wydzielić 3 warianty:
a) cała logika na bazie
b) rozsmarowana logika (część na bazie, część w aplikacjach)
c) cała logika w aplikacjach
Na to nakładamy dane historyczne w postaci ilości "change requestów", "ilości błędów" spowodowanymi rozsmarowaniem logiki vs. całkowita ilość CRów/ błędów

Na tej podstawie mieć narrację "gdyby logika była w jednym miejscu", to:

• ilość CRów/błędów ze względu na rozsmarowaną logikę byłaby 0 (to biznes może przeliczyć na kasę wydawaną w ciągu roku na obsługę CR/błędów -> oszczędność)
• koszt CRa zaimplementowanego na bazie / aplikacji (optymalizacja developmentu, taniej robić zmiany w miejscu X niż w Y)

Ot można zebrać dane i zbudować jakiś "biznes case" na przepisanie logiki do wybranej technologii i wykazać, że inwestycja zyliona $ zwróciłaby się po 3-5 latach, albo po trylionie lat i nie ma najmniejszego sensu tego robić, tylko dalej opłaca się rozsmarowywać logikę, bo biznes np. zakłada, że co 5-8 lat wymienia systemy.

yarel napisał(a):

Jak dla mnie można wydzielić 3 warianty:
a) cała logika na bazie
b) rozsmarowana logika (część na bazie, część w aplikacjach)
c) cała logika w aplikacjach

Trzy warianty a prawidłowego brak :), ja nie wiem co wy się tak upieracie albo na logikę biznesową w bazie albo jako alternatywę podajecie logikę biznesową rozproszoną w wielu aplikacjach. Oba podejścia w dzisiejszych czasach są uważane za nie najlepsze, w obu tych przypadkach to baza jest punktem integracji, a tego chcemy właśnie uniknąć. Za prawidłowe rozwiązanie uchodzi serwis zawierający logikę biznesową który pod spodem korzysta z jednego lub więcej źródeł danych. Także jak mamy wiele aplikacji, to wszystkie korzystają z jednego serwisu w którym jest cała logika biznesowa odpowiadająca danemu bounded contextowi i nikt poza tym jednym serwisem nie ma dostępu do jego źródeł danych.

neves napisał(a):

Trzy warianty a prawidłowego brak :), ja nie wiem co wy się tak upieracie albo na logikę biznesową w bazie albo jako alternatywę podajecie logikę biznesową rozproszoną w wielu aplikacjach. Oba podejścia w dzisiejszych czasach są uważane za nie najlepsze, w obu tych przypadkach to baza jest punktem integracji, a tego chcemy właśnie uniknąć.

Dla mnie różnica między aplikacją i serwisem nie jest jakaś super istotna i sprowadza się do potencjalnie innego interfejsu, więc może piszemy o tym samym, używając innych słów.
Co do bounded contextów , to ja bym się za bardzo nie przywiązywał do buzz wordów. Analitycy biznesowi pewnie mają niezły ubaw czytając jak wynaleziono event storming i jaki nowatorskie jest robienie warsztatów z kimś kto zna domenę :-)

@yarel:

1. nie ma czegoś takiego jak:

b) rozsmarowana logika (część na bazie, część w aplikacjach)

Jest to jakiś twór którym straszy się biedne użytkowniczki biznesowe na spotkaniach - dla jaj, jak jest piątek i się człowiek nudzi (a nie jest to Londyn).
Ale doświadczony programista wie, że nie musi traktować bazy jako osobny byt. Baza to po prostu kolejna warstwa tej samej aplikacji.

Zresztą, pewnie są systemy gdzie sprawdza się tylko podejście cała-logika-na-bazie.
Ja po prostu nie miałem okazji z takimi pracować.

vpiotr napisał(a):

@yarel:

1. nie ma czegoś takiego jak:

b) rozsmarowana logika (część na bazie, część w aplikacjach)

Jest to jakiś twór którym straszy się biedne użytkowniczki biznesowe na spotkaniach - dla jaj, jak jest piątek i się człowiek nudzi (a nie jest to Londyn).

Dla użytkowników biznesowych preferuję określenie "suboptymalne rozwiązanie" ;)

Ale doświadczony programista wie, że nie musi traktować bazy jako osobny byt. Baza to po prostu kolejna warstwa tej samej aplikacji.
Tej samej tak, chyba że mamy do czynienia z tematem integracji różnych systemów i baza się pojawia gdzieś jako element wspólny, ale to inna bajka.

Zresztą, pewnie są systemy gdzie sprawdza się tylko podejście cała-logika-na-bazie.

Może nie cała, ale nietrywialna w systemach, które korzystają np. z MVCC i wymagają jakiejś wspólnej warstwy do zarządzania wersjonowaniem danych. W takich sytuacjach serwisy, które są poza bazą przykrywają tylko wywołania API bazodanowego (do głowy przychodzi mi ArcGIS i rozwiązania oparte o ten produkt).