Logika aplikacji głównie w bazie danych

0

Wpis w mikroblogu od @woolfik nasuwa przypuszczenie że jest więcej sitów niż 1 gdzie logika aplikacji jest w całości lub większości przechowywana w bazie danych (np. w PL/SQL) - jego uzasadnienie jest przecież rozsądne (wiele aplikacji na jednej bazie).
Pytanie czy stosujecie takie podejście i czy stosowalibyście gdybyście mogli, a jeśli tak, to dlaczego?
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?

3

Nie ma co tłumaczyć, najlepiej zapytać w jaki sposób testują ją (logikę) jednostkowo i czy jej utrzymanie jest przyjemne :)

6

Miałem kiedyś wątpliwą przyjemność pracy przy projekcie, gdzie 80% logiki leżało po stronie bazy. Wniosek jest taki - mam nadzieję, że nigdy więcej na podobny projekt się nie natknę ;)

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...)

4

@DisQ: i tak zaraz w projekcie przyjdzie magik jeden z drugim i powiedzą, że wsadzamy wszystko do bazy, bo ORM'y są wolne, bo próbowaliśmy raz 15 lat temu i wtedy nie wyszło, a tak przynajmniej można zrobić jakieś drobne naprawy bez podmiany całej apki.

Happy debugging ;)

1

Wszystko zależy od architektury. Pracowałem przy bardzo dużym projekcie (jeden z większych polskich ERP), gdzie logika była po stronie bazy i praca była prosta i przyjemna, ponieważ ktoś całość dobrze przemyślał. Przykładowo w bazie została zaimplementowane repozytorium, które działało w ten sposób, że w momencie wrzucenia nowej wersji obiektu automatycznie tworzyła się ramka z nowym numerem wersji danego obiektu, którą trzeba było podpisać i zacommitować, oprócz tego wykonywały się testy, dzięki temu od razu było widać czy dana ramka jest dobrze przygotowana i przetestowana przed developera i nie psuje czegokolwiek innego.

Z tego też względu nie przekreślam z góry takiego rozwiązania.

8

Ja uważam, że to, iż ktoś się urodził w latach osiemdziesiątych XX wieku nie oznacza, że musi programować tak, jak się to robiło w tamtych czasach.

A baza danych to NIE JEST szyna integracji między systemami.

0
somekind napisał(a):

Ja uważam, że to, iż ktoś się urodził w latach osiemdziesiątych XX wieku nie oznacza, że musi programować tak, jak się to robiło w tamtych czasach.

Lubię sobie czasem poczytać bzdury, który wypisujesz. Programowanie funkcyjne to koncept z lat 50-tych czy to oznacza, że osoby które nie pamiętają Gomułki nie mogą lub nie powinny programować funkcyjnie?!

1

Czasem fajnie sobie poczytać rozmowy starych ludzi @Haskell i @somekind :D

8

Tak jak pisałem na mikroblogu Aby się nie powtarzać napiszę tylko tyle, że jeśli ktoś odpowiada za bazę jako całość to ma większą wiedzę niż developer frontendowy, który potrzebuje tylko gui dla swojego klienta. Przykład z RODO i dwie firmy.
1 Firma ma developerów, którzy na bazie przygotowują zestaw procedur/funkcji/widoków/pakietów dla pozostałych developerów i odpowiednie konto użytkownika, na które łączą się setki lub nawet tysiące aplikacji z odpowiednimi uprawnieniami. Zabezpiecza to bazę przed wrzucaniem czegokolwiek, skądkolwiek panuje ład i porządek.
2 Firma, która traktuje bazę wyłącznie jak składowisko danych więc każdy sobie rzepkę skrobie i z każdej aplikacji lecą niezależne I/U/D/S

Wchodzi RODO. Na środowiskach testowych trzeba zahashować NIP i NAZWĘ
W firmie A developer zmienia tylko widoki wystawione dla klientów zewnętrznych i ma załatwione RODO dla wszystkich systemów i aplikacji. Jeśli developerzy są sprytni to są w stanie to załatwić jednym selectem lecącym po grantach usera wystawionego aplikacjom zewnętrznym.
W firmie B każdy developer każdej aplikacji musi sam po swojej stornie w jakiś sposób dostosować się do RODO.

Nie wspomnę już o sytuacji gdzie np dane się nie pojawiają i trzeba ustalić, która aplikacja faktycznie nie wykonała swojej roboty. W przypadku pakietu / funkcji / procedury można to odpowiednio ubrać w logi i od razu wiemy jaka sesja, jaka maszyna, jakie dane, o której itd. wpadły do procedury.

Oczywiście teraz polecą argumenty w stylu ... przecież można zrobić webservice, na który będą się łączyć aplikacje. Tak można ale jest to dodatkowa aplikacja, która w znacznej większości się przydaje ale nie służy do tego żeby zarządzać logiką bazodanową. Finalnie taki webservice powinien zarządzać klientami, wystawiać api ale pod spodem też powinien odpalać odpowiednie procedury bazodanowe.

Nie chcę uogólniać ale wydaje mi się, że większość hejterów, którzy nie rozumieją tego podejścia to zwykli klepacze kodu, którym nie chciało się poświęcić kilku minut na naukę baz danych aby zrozumieć i docenić możliwości i zalety płynące z np PL/SQL.

2
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ć...

Sama logika w tej bazie nie jest już dla mnie takim problemem. Pomijając fakt, że większość aplikacji kompletnie nieptrzebnie korzysta z baz danych, albo korzysta ze złych.

1
woolfik napisał(a):

Oczywiście teraz polecą argumenty w stylu ... przecież można zrobić webservice, na który będą się łączyć aplikacje.

WebService, REST service, Web API, serwer RPC (np. JSON-RPC), kolejkę, szynę ESB (to ostatnie tylko w celach historycznych)...
Może @somekind brzmi czasem jak hejter, ale na serio, czasy gdy baza integrowała systemy już dawno minęły.
I jeśli ktoś twierdzi inaczej to chyba nigdy po prostu nie poznał nic innego.

Wyobrażasz sobie że ZUS (a raczej jego sensowna inkarnacja) wystawia bazę danych i procedury wbudowane do jej używania?
BTW, używają REST-a: https://www.infakt.pl/developers/insurance_fees.html

4
woolfik napisał(a):

Nie chcę uogólniać ale wydaje mi się, że większość hejterów, którzy nie rozumieją tego podejścia to zwykli klepacze kodu, którym nie chciało się poświęcić kilku minut na naukę baz danych aby zrozumieć i docenić możliwości i zalety płynące z np PL/SQL.

Ale większość osób wypowiadających się tutaj, przedstawiło konkretne argumenty dlaczego uważają, że takie rozwiązanie jest słabe i jakie ma wady. Hejterów w tym temacie akurat jest mało, co najwyżej dużo osób uważających, że to się nie sprawdza.

Jeśli zaś chodzi o zalety płynące z PL/SQL to uważam, że nie o tym jest temat ;) Nikt nie narzeka, że PL/SQL to zła technologia (jak każda inna, ma swoje zalety jak i wady). Problem dotyczy rozrzucenia logiki pomiędzy aplikacje, a bazę danych. Cała dyskusja rozbija się o to, czy zalety wynikające z tego rozwiązania (to o czym Ty mówisz) są wystarczająco duże, aby zrekompensować wady (to co kilka osób, w tym ja, napisało tutaj). I tak jak w pierwszym poście, tak i tutaj się powtórzę - moja opinia jest oparta o jeden projekt przy którym pracowałem, gdzie logika w bazie danych zwyczajnie się nie sprawdzała i nie zdziwię się, jeśli firma zdecyduje się na przepisanie całego systemu, bo zwyczajnie koszt utrzymania przewyższy koszt nowego oprogramowania.

5

Używam logiki w bazie danych. Przez to nie muszę się martwić żadną historią zmian, składowaniem dodatkowych danych o których "zwykły programista" nie musi wiedzieć. Udostępniam dane przez API, a jakże - poprzez widoki, a nie tabele - to już logika, czy jeszcze nie?
Udostępnianie przez RESTa, API czy jak to zwał nie wyklucza absolutnie korzystania z logiki bazodanowej - wg mnie ułatwia - ma spójność, że z każdego miejsca (aplikacja, www, czy też inny REST) zadziała dokładnie w ten sam sposób. Jedyny słuszny. I racja, jak się logika zmienia, to zmieniam TYLKO w jednym miejscu.
Ale bez przesady - nie wszystko jest na bazie... Umiar i zdrowy rozsądek wskazany.

2

Widziałem już kilka niezłych faili związanych z używaniem centralnej bazy danych do trzymania danych dla wielu aplikacji.
Ciekawy był, kiedy firmie groziły procesy sądowe ze strony klientów i urzędu skarbowego. Jeden z dostawców aplikacji mający dostęp do bazy danych zmienił sobie transaction isolation na read uncommitted, bo mu: szybciej działało. W efekcie niektóre faktury wystawiane przez użytkowników tej aplikacji miały niespójne dane i tak to poszło do skarbówki... (niemieckiej, przez pare miesięcy). Zanim odkryliśmy, że to klient - (firma stowarzyszona) sam sobie strzelił w kolano byliśmy długo pod obstrzałem, że to nasza wina bo im dawaliśmy złe dane. (tak to wynikało jasno z ich logów...)

2

Lubię, gdy ludzie których nigdy nie widać w dziale Bazy danych wchodzą tu i przedstawiają swój punkt widzenia.

2

OP powinien sprecyzować granicę kiedy logika jest na bazie, a kiedy jeszcze nie...
Ja mam wrażenie, że niektórzy programiści zatrzymali się na poznaniu prostych selektów, resztę załatwia ORM, a później tłumaczą to separacją od warstwy danych i delegowaniem logiki do wyższych warstw.
I w swoim zawodowym życiu widziałem już aplikacje, które w bazie trzymały tylko tabelę, a programiści o funkcjach agregujących słyszeli ale nie używali...
Znam system który 90% wykonuje po stronie bazy i działa sprawnie...
Przesada w żadną stronę nie jest dobra. Ta dyskusja jest bezproduktywna, bo nie ustaliliśmy kiedy logika po stronie DB jest "zła".
Moje spostrzeżenia (opierając się na subiektywnej ocenie, popartej doświadczeniem zawodowym) są takie, że najbardziej na umieszczenie czegoś w bazie, narzekają Ci którzy SQLa chcą używać jak język programowania, generalizując: walą ify zamiast poprawnie napisać where, albo iterują po danych zamiast wykorzystać silnik DB do tej pracy.
Ale co ja tam mogę wiedzieć...

3

Logika biznesowa w bazie danych?
https://m.youtube.com/watch?v=BFcgE3BC4aA

4
woolfik napisał(a):

1 Firma ma developerów, którzy na bazie przygotowują zestaw procedur/funkcji/widoków/pakietów dla pozostałych developerów i odpowiednie konto użytkownika, na które łączą się setki lub nawet tysiące aplikacji z odpowiednimi uprawnieniami. Zabezpiecza to bazę przed wrzucaniem czegokolwiek, skądkolwiek panuje ład i porządek.
2 Firma, która traktuje bazę wyłącznie jak składowisko danych więc każdy sobie rzepkę skrobie i z każdej aplikacji lecą niezależne I/U/D/S

Z tych dwóch propozycji też bym chyba wybrał pierwszą. Szkoda tylko, że nie podałeś przykładu 3 - firma, która ma rozsądną architekturę:

  1. W której system jest podzielony na moduły, z których każdy odpowiada za konkretny wycinek działalności.
  2. Każdy z modułów ma swoje własne źródło danych - odpowiednie do charakteru przechowywanych danych i pozostałych wymagań.
  3. Każdy moduł wystawia API programistyczne przez które faktycznie daje dostęp do konkretnych ficzerów z prawdziwą autoryzacją.

Wchodzi RODO. Na środowiskach testowych trzeba zahashować NIP i NAZWĘ

Hashować bo RODO? Ale czemu... o.O

W firmie A developer zmienia tylko widoki wystawione dla klientów zewnętrznych i ma załatwione RODO dla wszystkich systemów i aplikacji. Jeśli developerzy są sprytni to są w stanie to załatwić jednym selectem lecącym po grantach usera wystawionego aplikacjom zewnętrznym.

To jak w firmie 3.

Nie wspomnę już o sytuacji gdzie np dane się nie pojawiają i trzeba ustalić, która aplikacja faktycznie nie wykonała swojej roboty. W przypadku pakietu / funkcji / procedury można to odpowiednio ubrać w logi i od razu wiemy jaka sesja, jaka maszyna, jakie dane, o której itd. wpadły do procedury.

Tylko, że to samo, a nawet jeszcze więcej można zrobić po stronie webserwisu.

Finalnie taki webservice powinien zarządzać klientami, wystawiać api ale pod spodem też powinien odpalać odpowiednie procedury bazodanowe.

Powinien, bo tak jest w materiałach reklamowych producentów baz z lat 80tych.

vpiotr napisał(a):

Może @somekind brzmi czasem jak hejter, ale na serio, czasy gdy baza integrowała systemy już dawno minęły.

Jak widać, niestety nie minęły. I to anachroniczne podejście jest chyba jednym z powodów zacofania polskiego IT. Po prostu nie da się zrobić dobrego produktu na światowym poziomie w ten sposób.

I jeśli ktoś twierdzi inaczej to chyba nigdy po prostu nie poznał nic innego.

No cóż, na studiach przecież uczą, że projektowanie systemu zaczynamy od diagramu ERD oraz bazy danych. I tak już wielu zostaje na zawsze - po co się rozwijać, jeszcze się zmarszczki porobią.

Marcin.Miga napisał(a):

Używam logiki w bazie danych. Przez to nie muszę się martwić żadną historią zmian, składowaniem dodatkowych danych o których "zwykły programista" nie musi wiedzieć.

O jaką historię zmian Ci chodzi - rekordów czy kodu? I o jakie dodatkowe dane? Bo wygląda tak, jakbyś cieszył się, że nie musisz się martwić czymś, czym nikt się i tak nie martwi. :)

Udostępnianie przez RESTa, API czy jak to zwał nie wyklucza absolutnie korzystania z logiki bazodanowej - wg mnie ułatwia - ma spójność, że z każdego miejsca (aplikacja, www, czy też inny REST) zadziała dokładnie w ten sam sposób. Jedyny słuszny. I racja, jak się logika zmienia, to zmieniam TYLKO w jednym miejscu.

Ależ w przypadku poprawnie zaprojektowanego systemu, w którym wszystkie aplikacje klienckie i strony WWW korzystają z jednego webserwisu też masz spójność i jedno miejsce do zmiany.

Panczo napisał(a):

OP powinien sprecyzować granicę kiedy logika jest na bazie, a kiedy jeszcze nie...
Ja mam wrażenie, że niektórzy programiści zatrzymali się na poznaniu prostych selektów, resztę załatwia ORM, a później tłumaczą to separacją od warstwy danych i delegowaniem logiki do wyższych warstw.

Ja za to mam pewność, że to fanatycy baz danych nie znają innych technologi, narzędzi i architektur. Znają jeden młotek, więc używają go do wszystkiego. A potem rozwiązują problemy typu rekurencyjnie wywołujące się triggery do wysyłania maili. I takim sytuacjom nie da się przeciwdziałać, bo SQL jest tak naprawdę trudny, a testowanie baz danych jest znacząco utrudnione.

I w swoim zawodowym życiu widziałem już aplikacje, które w bazie trzymały tylko tabelę, a programiści o funkcjach agregujących słyszeli ale nie używali...
Znam system który 90% wykonuje po stronie bazy i działa sprawnie...

Tu nie chodzi o sprawne działanie, lecz o czas oraz efektywność wytworzenia oprogramowania, łatwość testowania, niezawodność, możliwości instrumentacji i skalowania.

Przesada w żadną stronę nie jest dobra. Ta dyskusja jest bezproduktywna, bo nie ustaliliśmy kiedy logika po stronie DB jest "zła".

Zawsze, z wyjątkiem operacji zbyt czasochłonnych, aby je wykonywać albo implementować po stronie aplikacji. Czyli np. operacji wsadowych, importu/eksportu z zewnętrznych źródeł, generowania raportów.

Nie ma powodu umieszczać w bazie więcej logiki niż to absolutnie konieczne, bo:

  1. Pisanie prostych CRUDów to czynność uwłaczająca istocie ludzkiej. Proste automatyzowane czynności należy generować automatycznie i nie tracić na to czasu.
  2. Nie da się testować jednostkowo, możliwe są jedynie testy integracyjne. I nawet testując jedną rzecz na raz te testy będą znacząco wolne od testów kodu aplikacji.
  3. Języki aplikacji są generalnie bardziej ekspresywne niż SQL, więc jest mniej kodu do napisania i utrzymania.
  4. Większe możliwości logowania, instrumentacji, monitorowania, ograniczania dostępu, rate limitowania i innych tego typu infrastrukturalnych kwestii.
  5. Skalowalność - relacyjne bazy danych skalują się trudno. Dobrze zaprojektowany system sam skaluje te moduły, które tego wymagają.
  6. Dopasowanie źródła danych do problemu - często nie ma sensu trzymać danych konfiguracyjnych, dokumentów, grafów obiektów, plików w bazach relacyjnych. Mając modularny system nie jest problemem dobranie sposobu przechowywania do charakteru danych. A jeśli wszystko wpycha się do bazy relacyjnej, to potem często kończy się beznadziejną wydajnością.a
0
somekind napisał(a):

Powinien, bo tak jest w materiałach reklamowych producentów baz z lat 80tych.

vpiotr napisał(a):

Może @somekind brzmi czasem jak hejter, ale na serio, czasy gdy baza integrowała systemy już dawno minęły.

Jak widać, niestety nie minęły. I to anachroniczne podejście jest chyba jednym z powodów zacofania polskiego IT. Po prostu nie da się zrobić dobrego produktu na światowym poziomie w ten sposób.

Relacyjne bazy danych praktycznie nie zmieniły się od samego początku, a mimo wszystko i tak każdy z baz korzysta.

Ja za to mam pewność, że to fanatycy baz danych nie znają innych technologi, narzędzi i architektur. Znają jeden młotek, więc używają go do wszystkiego. A potem rozwiązują problemy typu rekurencyjnie wywołujące się triggery do wysyłania maili. I takim sytuacjom nie da się przeciwdziałać, bo SQL jest tak naprawdę trudny, a testowanie baz danych jest znacząco utrudnione.

Tu przeginasz w drugą stronę ... sytuacje jakie opisuję na mikroblogu to właśnie przegięcie ale tak może być w każdym języku czy technologii. Natomiast jeśli piszesz, że SQL jest trudny ... no to ja nie mam pytań.

Tu nie chodzi o sprawne działanie, lecz o czas oraz efektywność wytworzenia oprogramowania, łatwość testowania, niezawodność, możliwości instrumentacji i skalowania.

Jeśli dla ciebie szybkość wytwarzania oprogramowania jest ważniejsza niż jej sprawne działanie to widzę, że awansowałeś na level PM i powinieneś dostać bana na 4p

Nie ma powodu umieszczać w bazie więcej logiki niż to absolutnie konieczne, bo:

  1. Pisanie prostych CRUDów to czynność uwłaczająca istocie ludzkiej. Proste automatyzowane czynności należy generować automatycznie i nie tracić na to czasu.

I za tą wypowiedź należy Ci się tydzień w piekle. Wyobraź sobie, że przychodzi PM i mówi ... od dziś musimy rejestrować w każdej tabeli informacje o tym, kto zrobił dany wpis. Ja Ci kuźwa życzę powodzenia jak będziesz musiał szukać poszczególnych developerów z poszczególnych aplikacji aby poprawiali swoje "wyklikane" CRUD'y i potem robisz testy regresji wszystkich mechanizmów ... powodzenia @somekind powodzenia

  1. Języki aplikacji są generalnie bardziej ekspresywne niż SQL, więc jest mniej kodu do napisania i utrzymania.

bullshit

0
Panczo napisał(a):

OP powinien sprecyzować granicę kiedy logika jest na bazie, a kiedy jeszcze nie...
Ja mam wrażenie, że niektórzy programiści zatrzymali się na poznaniu prostych selektów, resztę załatwia ORM, a później tłumaczą to separacją od warstwy danych i delegowaniem logiki do wyższych warstw.

@Panczo, to jest dyskusja w skrócie o PL/SQL - czyli triggery, procedury, funkcje, pakiety i wyjątki.
O tym że robisz wystawienie FV przy pomocy procedury typu "wystaw_fv" albo "zaksieguj_przelew" zamiast zaimplementować to w ludzkim języku.

Uprzedzam, że wiem że jest możliwość napisania SP np. w Javie czy w C#, ale jakoś nie słyszałem żeby ktoś tego używał.

3

@somekind:

Ja za to mam pewność, że to fanatycy baz danych nie znają innych technologi, narzędzi i architektur. Znają jeden młotek, więc używają go do wszystkiego. A potem rozwiązują problemy typu rekurencyjnie wywołujące się triggery do wysyłania maili. I takim sytuacjom nie da się przeciwdziałać, bo SQL jest tak naprawdę trudny, a testowanie baz danych jest znacząco utrudnione.

Tu muszę Ci przyznać rację znam sporo takich. 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. Testowanie jest możliwe, ale faktycznie "klasyczny" kod wypada pod tym względem lepiej.

Tu nie chodzi o sprawne działanie, lecz o czas oraz efektywność wytworzenia oprogramowania, łatwość testowania, niezawodność, możliwości instrumentacji i skalowania.

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

Zawsze, z wyjątkiem operacji zbyt czasochłonnych, aby je wykonywać albo implementować po stronie aplikacji. Czyli np. operacji wsadowych, importu/eksportu z zewnętrznych źródeł, generowania raportów.

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

Nie ma powodu umieszczać w bazie więcej logiki niż to absolutnie konieczne, bo:

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

@vpiotr: przecież wyszedłeś od wpisu @woolfik, który pokazał skrajny przypadek i został podany jako ciekawostka, ja rozumiem, że chcesz się dowiedzieć czy jest tak gdzieś jeszcze i jak napisałem wcześniej znam bardziej radykalne podejście niż to przedstawione przez insert do tabeli z 45 triggerami. Jako ciekawostkę dodam że system z praktycznie całą logika na bazie powstał dlatego, że teamy DB (tu silnikiem był MS SQL) i Dev postanowiły sobie zrobić udowadnianie wyższości świat bożego narodzenia na wielkanocą i zrobiły konkurs, kto zaimplementuje szybciej rozwiązanie i które będzie szybsze. Stawką było w jaki sposób ta logika będzie zaszyta w programie. Wiadomo kto wygrał ;) Na marginesie powiem, że widziałem tę bazę i stał za tym naprawdę wyjadacz DB (w zakresie MS SQL) i było to naprawdę fajnie zaimplementowane, jako przeciwnik takich rozwiązań, nie miałbym problemów aby się w to wpasować...

1

Znam przypadek, jak jeden programisty javy ładował dwie tabele bazodanowe (każda po około 2 GB) do tablic w javie i wykonywał na nich operacje join :D. Obliczenia na tych tablicach wykonywane były w nocy więc nikomu to nie przeszkadzało, rano wynik był gotowy. Nikt z pracowników firmy nie chciał tego ruszać bo program był pisany przez jedną z większych firm outsourcingowych i modyfikacja wiązała by się z utratą gwarancji. Wystarczyło napisać prostego selecta łączącego dwie tabel lub wystawić widok.

2

Co do osób które zarzucają przeciwnikom stosowania logiki biznesowej w BD to że niby umieją korzystać tylko z ORM i w ogóle nie są into SQL -> nie prawda, sam czasami preferuje SQL nad ORM do wczytywania danych, bo często ready w ORM są po prostu słabe. @somekind też kiedyś pisał o tym że robi podobnie, więc wyobraźcie sobie że to nie jest tak że nie umiem SQL == nie lubie logiki w BD
Pozdrawiam cieplutko :)

2

@scibi92: bo do postawionego zadania czy problemu należy stosować odpowiednie narzędzia. Też nie mam nic przeciwko ADO i zwróceniu wyniku zapytania z jakiejś procedury składowanej w przypadku gdy np. posklejanie bardzo skomplikowanego selecta przez ORM wygląda jak graffiti kiepskiego malarza, z którego nic nie wiadomo. Zresztą są dziedziny, w których ORM'ów i tak nie użyjesz vide np. zapytania MDX'owe z OLAP'a.

Bardzo lubię używać narzędzi typu ORM ale są oczywiście wyjątki gdzie tradycyjne podejście jest lepsze. A samego SQL'a trzeba znać, no bo niby jak zinterpretujesz to co leci z ORM'a do bazy?

Z tego samego powodu nie cierpię skomplikowanych kwerend Linq, gdzie muszę odszyfrowywać co autor miał na myśli pisząc spaghetti zamiast np. jakiś fragment kodu zamknąć zwykłą pętlą, bo nie... "trzeba walnąć Linq, bo to modne".

4
woolfik napisał(a):

Relacyjne bazy danych praktycznie nie zmieniły się od samego początku, a mimo wszystko i tak każdy z baz korzysta.

Każdy w rezerwacie, bo na świecie jest masa alternatywnych rozwiązań dopasowanych do konkretnych problemów.

Tu przeginasz w drugą stronę ... sytuacje jakie opisuję na mikroblogu to właśnie przegięcie ale tak może być w każdym języku czy technologii.

Owszem. Dlatego sens jest porównywać dobre rozwiązania z obu podejść, a nie jedno dobre z drugim niepoprawnym.

Natomiast jeśli piszesz, że SQL jest trudny ... no to ja nie mam pytań.

Skoro tak łatwo się w nim pisze skomplikowane systemy, to znaczy, że sytuację na mikroblogu wymyśliłeś sam, bo w rzeczywistości nie mogła mieć miejsca.

Jeśli dla ciebie szybkość wytwarzania oprogramowania jest ważniejsza niż jej sprawne działanie

A gdzie ja tak napisałem?

to widzę, że awansowałeś na level PM i powinieneś dostać bana na 4p

No tak, brak argumentów technicznych, więc zaczyna się ad personam. Typowe.

I za tą wypowiedź należy Ci się tydzień w piekle. Wyobraź sobie, że przychodzi PM i mówi ... od dziś musimy rejestrować w każdej tabeli informacje o tym, kto zrobił dany wpis. Ja Ci kuźwa życzę powodzenia jak będziesz musiał szukać poszczególnych developerów z poszczególnych aplikacji aby poprawiali swoje "wyklikane" CRUD'y i potem robisz testy regresji wszystkich mechanizmów ... powodzenia @somekind powodzenia

Nie wiem o jakich wyklikanych CRUDach bredzisz. To, że Ty znasz jeden sposób tworzenia softu, to nie znaczy, że inni ludzie nie potrafią programować normalnie.
Ja cały czas piszę o tym, że jest JEDNA aplikacja, która dane do bazy wstawia. I jedno miejsce w kodzie, w którym zatwierdza się transakcję, ergo rejestrowanie takich zmian dla wszystkich tabel to kilka linijek w jednej funkcji.

1

Dobra Panowie bo tutaj zaczyna się robic wykop a nie chcemy siedziec w brodziku intelektualnym. Toteż wypijcie sobie brudzia na zgodę i do roboty. Ktos musi poprawić ten zastany syf.;)

2

Ja w ogóle bym używania czystego SQL do odczytywania danych z bazy nie uznawał za logikę, ot po prostu przedstawienie danych w mniej lub bardziej zdenormalizowanej/zagregowanej formie. Pod warunkiem że to odczytywanie nie zawiera w sobie jakiś instrukcji warunkowych pochodzących od biznesu. Oczywiście jest to wbrew definicji z Wikipedii która za logikę uznaje praktycznie wszystko poza infrastrukturą ;). Zresztą ORM'y nie mają zwykle problemów z mapowaniem widoków czy procedur.

Natomiast wszelkie procedury i triggery z efektami ubocznymi(zapisami), przetwarzanie pojedynczych wierszy w procedurach czy funkcjach zgodnie z procesami biznesowymi, narzucanie jakiś dodatkowych więzów integralności pochodzących z reguł biznesowych za pomocą procedur czy triggerów, skomplikowane obliczenia biznesowe, to zło dopuszczalne tylko wtedy kiedy analogiczne rozwiązanie po stronie kodu byłoby przynajmniej o rząd wielkości wolniejsze.

5

Pracowałem nad kilkoma systemami w których logika była umieszczona w bazie danych, w różnych proporcjach. 2 duże systemy, około 50-60% logiki w bazie danych, 1 system - 95% logiki w bazie danych.Ze słyszenia znam jeszcze 1 system w którym java wykorzystywana jest jedynie jako frontend, a wszystko dzieje się w bazie danych. Jeden z tych systemów projektowałem (50% logiki w bazie). Nie wiem co przyświecało architektom innych systemów, ale podejrzewam że tak jak mnie, potrzeba wydajności osiągalna w rozsądnej cenie. Przeniesienie części procesów biznesowych systemu taryfikacyjnego do warstwy bazodanowej skutkowało przyspieszeniem tych operacji o rząd wielkości. Po prostu duże ilości danych najszybciej obrabia się biznesowo u źródła - w bazie danych .W takim przypadku nie ma problemu z tym, że technologia jest mało popularna, że programistów jest mniej i być może bardziej się cenią (lub nie), że trudniej to utrzymać i przetestować.. Liczy się to, że końcowy użytkownik oprogramowania, jest w stanie w określonym,skończonym czasie wystawić faktury dla swoich klientów. I w zasadzie tylko to. Przy pozostałych systemach z którymi miałem do czynienia, mogę się domyślać że projektantami systemów kierowała ta sama przesłanka - wydajność obróbki dużej ilości danych przepuszczanych przez multum procesów biznesowych, umożliwiająca zadziałanie procesów biznesowych w "czasie skończonym". Najczęściej systemy takie spotyka się w bankach, firmach ubezpieczeniowych, operatorach telekomunikacyjnych, energetyce. Czyli w tej trochę bardziej nudnej i mniej popularnej dziedzinie biznesu.
Dla równowagi, pracowałem także przy systemach, gdzie ORM był posunięty do granic absurdu - używane własne, wielowarstwowe biblioteki mapujące, każda operacja to w zasadzie wczytywanie setek megabajtów danych z bazy, często tylko i wyłącznie w celu zmiany jednego atrybutu w wybranych encjach. Wszystko narzucone odgórnie przez "architektów" końcowego klienta. Skrajnie niewydajne, a przez totalnie przekombinowaną architekturę tej warstwy, także skrajnie ciężkie w oprogramowaniu i użyciu. Ja osobiście wybieram w takim przypadku zwięzłość logiki w bazie , niż przekopywanie się przez dziesiątki plików źródłowych. W tym konkretnym przypadku oczywiście. Ogólnie, nie skreślam żadnego z podejść. Do każdego problemu potrzebne jest odpowiednie narzędzie. Oczywiście, ja tu piszę o wydajności, ale pisać bardzo źle i niewydajnie w bazach danych też się da. Później poprawiam i optymalizuje takie procesy biznesowe, które trwają u klienta 50h, a muszą zmieścić się w 5, bo takie okienko w nocy jest przewidziane, a szybszej macierzy dyskowej już się nie da dołożyć.
W niektórych przypadkach można sobie postawić pytanie - jeżeli nie w bazie danych, to gdzie? I powstają czasami takie cuda jak "baza danych napisana od podstawy w całości w javie, działająca wyłacznie w pamięci RAM". Jasne, można wymyślać koło od nowa, zamiast kupić coś takiego od doświadczonego producenta baz danych. Pytanie tylko, czy tak na pewno będzie lepiej i taniej. Szczerze wątpie.
Oczywiście dywagacje takie mają sens w przypadku systemów, których nie wyniesie się do AWS czy AZURE, gdzie można sobie dokupić rdzeniów czy przepustowości. Czyli banki ,etc.... Jak wyżej.

2

ORM nad ORMem to przegiecie w druga strone. Zyjemy w czasach gdy na ludzi znajacych SQLa patrzy sie jak na dziwakow z poprzedniej epoki. Zakladam jednak ze w kazdym zespole jest co najmniej jedna osoba ktora potrafi samodzielnie zbudowac query z warunkami where i odpowiednim grupowaniem.

Implementacja wysylania maila w triggerze to wg mnie drugi koniec na skali intensywnosci wykorzystania funkcjonalnosci DBMSa. Podejrzewam ze taka architektura moze wynikac z tego ze architekt (rola lub hobby) odbyl o jedno szkolenie z baz danych za duzo a nie mial nikogo w firmie kto by go utemperowal. Widzialem juz takie sytuacje.

No i przypominam ze dyskusja jest o tym czy implementowac wiekszosc logiki w bazie czy nie, a nie czy w ogole uzywac procedur. Stosowanie procedur to jedna z form optymalizacji, mozna tez zastosowac przetwarzanie zbiorowe lub przeprojektowac baze - jesli zwykly select nie wystarcza.
Ale stosowanie procedur by default "bo tak jest szybciej" to zupelnie co innego i o takim podejsciu chcialem podyskutowac.

0
vpiotr napisał(a):

ORM nad ORMem to przegiecie w druga strone. Zyjemy w czasach gdy na ludzi znajacych SQLa patrzy sie jak na dziwakow z poprzedniej epoki. Zakladam jednak ze w kazdym zespole jest co najmniej jedna osoba ktora potrafi samodzielnie zbudowac query z warunkami where i odpowiednim grupowaniem.

Serio? To już tak daleko zaszło?

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