Trzymanie logiki biznesowej po stronie bazy danych

Odpowiedz Nowy wątek
2016-08-08 09:29
0

Witam
Ostatnio utrzymuje system, który całą niemal logikę biznesową ma po stronie bazy danych. Mamy multum procedur, zdublowanego kodu. Złamane wszelkie zasady dobrego kodu. Ostatnio pisałem również jakieś dodatki do Comarcha XL, tam również wiele rzeczy dzieje się po stronie bazy danych. Pytanie moje jest następujące dlaczego trzyma się lwią część funkcjonalności po stronie bazy ? Jakie są tego korzyści ? Kod SQL jest trudny do czytania, utrzymania i ciężko wyłapać w nim błędy (nie mówimy o prostych zapytaniach, ale o złożonych procedurach).

Pozostało 580 znaków

2016-08-08 09:40
2

Zwykle nie ma korzyści, a wręcz przeciwnie. Czemu tak niektórzy robią? Bo są głupi ;] Ewentualnie bo naklepali taki kod, że łatwiej już bylo hackować po stronie bazy niż poprawić po stronie softu. 1% to sytuacje gdzie wydajność gra kluczową rolę i konieczne są cuda na kiju po stronie bazy danych (ale i wtedy zwykle to jest malutki fragment logiki, jakieś wąskie gardło)


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
@Shalom niekoniecznie. W przypadku systemów gdzie masz wiele GUI (desktop/mobile/web) to wsadzenie logiki po stronie bazy zapewnia Ci spójność wyników wyjściowych na wszystkich GUI bez konieczności modyfikacji wszystkich aplikacji. - woolfik 2016-08-08 12:47
takie coś się załatwia serwerem aplikacji a nie procedurami w bazie - abrakadaber 2016-08-08 20:18
@woolfik od tego robi się RESTowy endpoint z którego te UI korzystają. Tzw model Backend-as-a-service. - Shalom 2016-08-08 20:26
No i kolejna warstwa na której mogą pojawić się problemy. Dobrze oprogramowana baza danych + odpowiednie granty i żadna dodatkowa warstwa nie jest potrzebna. Nie mówię, że takie rozwiązanie jest jedyne słuszne ale wiele firm/korporacji stosuje właśnie taki model czy się to komuś podoba czy nie. - woolfik 2016-08-08 21:38

Pozostało 580 znaków

2016-08-08 10:30
1

Co do zasady nie ma sensu. W praktyce jest pewna klasa problemów, gdzie przeniesienie logiki do bazy danych pozwala na znaczącą redukcję ilości kodu. Chodzi tu szczególnie o sytuacje, w których proces przetwarzania danych musi zachować ich spójność. Baza danych, w szczególności relacyjna, posiada mechanizmy pozwalające na kontrolę spójności oraz kontrolę procesu przetwarzania tak by ewentualna awaria nie naruszyła danych.

Miałem do czynienia z apką, która pracowała w modelu MmVmC (Model - multiView - multiController), gdzie zmiany spływały z różnych źródeł i były wystawiane w różny sposób dla klientów. Na poziomie bazy znacznie łatwiej było to ogarniać, bo była pierwszy (i jedynym) miejscem gdzie mogliśmy sprawdzić, czy różne systemy nie próbują wchodzić sobie w drogę.

Niemniej pewnie dałoby sie zrobić jakąś fasadę-serwis który zasłaniałby dostęp do bazy i to z nim by się wszystko komunikowało ;) - Shalom 2016-08-08 10:46
@Shalom, nasza apka robiła mniej więcej to o czym mówisz. Wystawiała RESTy, wypluwała JSONy i dokumenty excela. Duża część DAO była napisana na zasadzie wywołaj procedurę. - Koziołek 2016-08-08 12:09
Chodziło mi o to że Na poziomie bazy znacznie łatwiej było to ogarniać, bo była pierwszy (i jedynym) miejscem gdzie mogliśmy sprawdzić, czy różne systemy nie próbują wchodzić sobie w drogę -> zamiast tego mógł być jakiś broker po drodze który służyłby koordynacji komunikacji z tymi innymi systemami :) - Shalom 2016-08-08 12:18
Za dużo zbyt skomplikowanych danych (dużo zależności w modelu, część wyliczana dynamicznie, część brana z dodatkowych źródeł). Lepiej dodać ograniczenie czy FK i obsługę wyjątku po stronie Javy. - Koziołek 2016-08-08 12:26

Pozostało 580 znaków

2016-08-08 12:44
0

Inna sprawa, że kiedyś była taka moda aby jak najwięcej upchać po stronie bazy danych.

Tradycyjna wyliczanka sprzed ładnych kilku lat z Oracle'owej książki albo publikacji (cytat z pamięci + tłumaczenie własne):

  1. Jeśli nie da się czegoś zrobić w SQLu, zrób to w PL/SQLu (PL/SQL można zamienić na t-SQL itp.)
  2. Jeśli nie da się czegoś zrobić w PL/SQLu, zrób to w Javie (Javę można zmienić na C# itp.)
  3. Jeśli nie da się czegoś zrobić w Javie, to zrób to w funkcji C (znowu pewnie dałoby się to zamienić)
  4. Jeśli nie da się czegoś zrobić w C, to zastanów się jaki jest sens to robić?

Co do zasadności operacji po stronie DB - to ma sens tylko przy dużych operacjach, w większości te operacje powinny być robione po stronie back-endu.

Pozostało 580 znaków

2016-08-11 15:00
jarek000000
0

Sa dwie ciekawe skrajnosci:
1) wszystko po stronie bazy danych (procedury skladowane etc.)

  • ma sens jesli masz zespol starych wyjadaczy Oracle, MS SQL, ktory potrzebuje Jave lub C# np. tylko jako Proxy do WEBa,
  • w innym przypadku zwykle zabija zespol (frustracja na debugu) i projekt (nie da sie Cache wprowadzic),

2) wszystko w Javie - a cala baza danych ukryta pod jakims ORM (JPA/Hibernate), fajnie - tylko to oznacza, ze baza danych (SQL) w ogole nie byla do niczego potrzebna

Pozostało 580 znaków

2016-08-11 15:16
1
a.dudek76 napisał(a):

Pytanie moje jest następujące dlaczego trzyma się lwią część funkcjonalności po stronie bazy ?

Abstrahując kompletnie od zalet i wad takiego rozwiązania spójrzmy na to z perspektywy historycznej. Zapewne są to systemy które powstały kilka(naście) lat temu, w czasach w których architektura aplikacji biznesowych była skierowana przede wszystkim na dane i sposób ich przechowywania. W dzisiejszych czasach ciężar zdecydowanie z danych przesunął się na logikę biznesową, a sposób przechowywania danych traktuje się jako szczegół implementacyjny.


Java to taki C# tyle że z gorszą składnią.

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