Trzymanie logiki biznesowej po stronie bazy danych

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

3

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)

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

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.

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

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

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