it-swarm.dev

Jakie są argumenty przeciwko lub za umieszczeniem logiki aplikacji w warstwie bazy danych?

[~ # ~] note [~ # ~] Odbiorcy programmers.se i dba.se są różni i będą mieli różne punkty widzenia, więc w w tym przypadku myślę, że można powielić jakie są argumenty przeciwko logice aplikacji lub za umieszczeniem jej w warstwie bazy danych? na programmers.se.

Nie mogłem znaleźć dyskusji na temat dba na ten temat, a oryginalny post mówi o tym wszystkim, więc:

Większość programistów chce zachować logikę aplikacji w warstwie aplikacji i prawdopodobnie wydaje nam się to naturalne, aby ją tutaj zachować. Deweloperzy baz danych wydają się chcieć umieścić logikę aplikacji w warstwie bazy danych jako wyzwalacze i procedury składowane.

Osobiście wolałbym zachować jak najwięcej w warstwie aplikacji, aby ułatwić debugowanie i oddzielenie obowiązków warstw.

Jakie są twoje przemyślenia na ten temat i co powinno być lub nie powinno być w porządku do wdrożenia w warstwie bazy danych?

N.B. Nie jestem OP dla tego pytania, ale nie zmieniłem oryginalnego brzmienia.

74
Phil Lello

Różne myśli ...

Kod bazy danych przeżyje technologię klienta aplikacji. Pomyśl o ADO.NET -> Linq -> EF, a także o różnych ORM. Podczas gdy nadal możesz uruchamiać kod SQL Server 2000 od ostatniego tysiąclecia dla wszystkich powyższych technologii klienckich.

Masz również problem z wieloma klientami: Mam .net, Java i Excel. To 3 zestawy logiki aplikacji.

„Logiki biznesowej” nie należy mylić z „logiką integralności danych”. Jeśli masz klientów rozpoczynających transakcje i wykonujących różne kontrole, jest to dużo wywołań db i długa transakcja.

Logika aplikacji nie jest skalowana w przypadku dużych ilości danych. Mamy 50 000 wierszy na sekundę przy użyciu zapisanych procesów. Drużyna siostrzana korzystająca z Hibernacji nie może uzyskać jeden na sekundę

56
gbn

Chcę całej logiki, która musi obowiązywać wszystkich użytkowników i wszystkie aplikacje w bazie danych. To jedyne rozsądne miejsce.

W ostatniej Fortune 500, w której pracowałem, aplikacje napisane w co najmniej 25 językach trafiały do ​​ich OLTP. Niektóre z tych programów przeszły do ​​produkcji w latach 70. XX wieku).

Alternatywą dla implementacji tego rodzaju wymagań w bazie danych jest umożliwienie każdemu programistowi aplikacji 100% poprawnej implementacji całości lub jego części, za każdym razem, gdy uruchamiają edytor, od pierwszego przejścia przez drzwi do momentu, gdy firma wyjdzie biznes.

Jakie są szanse?

Czy to nie jest największy „ nie powtarzaj się ” na planecie?

Przesuwam swoją starą odpowiedź bez edycji z programmers.se, ponieważ odpowiedzi wydają się dość spolaryzowane między stronami.

Wiem, że czeka mnie świat cierpienia, ale umieściłem logikę biznesową w bazie danych, ponieważ:

  • Możesz zezwolić zaawansowanym użytkownikom biznesowym na bezpośredni dostęp do bazy danych i nie martwić się, że to zepsują (lub martw się mniej niż w przypadku logiki opartej na aplikacji)
  • Zaawansowany użytkownik może tworzyć nowe raporty bez czekania na nową wersję oprogramowania.
  • Możesz przetestować kod SP/TRIGGER) w kopii bazy danych, podobnie jak testujesz logikę opartą na aplikacji
  • Możesz zachować SQL, aby tworzyć sp i wyzwalacze w plikach tekstowych (powinieneś to robić i tak w przypadku kodu tabeli/widoku)
  • Możesz mieszać i dopasowywać języki bez przenoszenia logiki biznesowej
  • Możesz wprowadzać zmiany w logice biznesowej bez aktualizacji każdego oprogramowania
  • Struktura audytu zmienia się w taki sam sposób, jak kontrolujesz aktywność bazy danych - poprzez rejestrowanie
  • Znacząco poprawione bezpieczeństwo i drobnoziarnista kontrola dostępu (większość implementacji logiki opartych na aplikacjach korzysta z własnego modelu bezpieczeństwa, więc dane są znacznie łatwiejsze do złamania. Odwracalne szyfrowanie hasła nie jest rzadkością)
  • Bezpieczeństwo użytkownika po stronie bazy danych znacznie zmniejsza szkody, które może wyrządzić nieuczciwy SQL

Wady: - programistom grożono, gdy użytkownicy stają się mniej zależni od programistów w zakresie raportów niestandardowych - programiści muszą nauczyć się innego języka programowania

Żadne z nich nie powinno mieć znaczenia dla wykwalifikowanego programisty.

Co ciekawe, większość odpowiedzi mówi w kategoriach „logiki aplikacji”, a nie „logiki biznesowej”, tak jakby oprogramowanie nie zapewniało funkcji biznesowej.

29
Phil Lello

Najważniejsze jest to, czy jakakolwiek „warstwa” nad bazą danych uważa, że ​​jest ona właścicielem danych. Współbieżność i integralność danych to problemy, dla których rozwiązaniem jest RDBMS - niektóre aplikacje są opracowywane tak, jakby baza danych była tylko ich osobistym zasobnikiem bitów i oczywiście próbują na nowo wymyślić koło na różne sposoby, a także nieodwracalnie uszkodzone, gdy tylko jakaś inna aplikacja uzyska dostęp do tej samej bazy danych

Zapisałem swoją odpowiedź na to na moim blog . Mój wniosek jest następujący: robienie tego w aplikacji po prostu nie jest skalowane po uwzględnieniu całego cyklu życia aplikacji.


3. Dodaj ograniczenia integralności/sprawdzania do bazowej bazy danych, z bardziej złożonym kodem zaimplementowanym w języku procedury składowanej bazy danych. Dzięki temu uzyskujemy jedną centralną lokalizację do utrzymania i uzyskujemy absolutne egzekwowanie reguł nawet w przypadku aplikacji, o których nie wiemy! Otrzymujemy jeden język do wyrażania reguł biznesowych w całym portfolio aplikacji i cyklu życia, ponieważ język du Jour zmienia się znacznie częściej niż baza danych. Działa w systemie, który jest tak samo krytyczny jak najważniejsze aplikacje. Błędy są obsługiwane przez istniejący kod, który obsługuje błędy bazy danych w tych aplikacjach. Nadal istnieje ryzyko, że aplikacja może się zepsuć, ale z trzech scenariuszy jest to co najmniej i tylko zepsuta aplikacja wymaga modyfikacji, nie wszystkie (a większość mechanizmów SP/bazy danych pozwoli na wyjątek stworzony dla jednej aplikacji, jeśli jest to naprawdę, naprawdę konieczne). Myślisz, że to nie ma znaczenia w Twojej witrynie greenfield lub małej firmie? Cóż, jeśli twój biznes odniesie sukces, za 30 lat będziesz żałować, że nie posłuchałeś mojej mądrości!

… Niektóre [obiekcje] często słyszę:

  • Trudno jest kontrolować wersję SP wdrożony w DB. Nie sądzę, żeby to było prawdziwsze niż stwierdzenie, że to trudna do kontroli wersji Java wdrożony na serwerze aplikacji, co oznacza, że ​​wcale nie jest trudny, jest powszechny. A w Ruby-land całe książki są pisane tylko o jak wprowadzić kod ze środowiska programistycznego do produkcji, coś, z czym nie zmaga się żadna inna społeczność językowa. Jednak kontrola wersji procedury przechowywanej jest najwyraźniej zbyt trudna.
  • Procedury przechowywane są trudne do przetestowania. To jest dziwne. Na początek SP są mocno wpisane; kompilator powie ci, czy istnieje ścieżka wejściowa lub wyjściowa kodu, która nie ma sensu, a przynajmniej w Oracle obliczy wszystkie zależności. To jest jeden zestaw typowych testów jednostkowych, które mogą być potrzebne w Ruby wyeliminowane z nietoperza. Aby przetestować OO wymaga wyśmiewania, aby zmusić obiekt do stanu wewnętrznego) wymagane do przedstawienia scenariusza testowego - w jaki sposób konfiguracja danych testowych jest inna? Istnieje producent TAP dla PL/SQL i innych narzędzi, są też debugery i profile.
  • Język procedury składowanej nie jest językiem w pełni funkcjonalnym. Cóż, nie próbujemy pisać całej aplikacji tylko w procedurach przechowywanych! Najbardziej dedykowane języki SP mają wszystkie nowoczesne konstrukcje, których można się spodziewać, a przynajmniej w Oracle można użyć Java Procedury składowane ze wszystkimi funkcjami językowymi = OO programiści są zaznajomieni z zewnętrznymi procedurami w dowolnym języku. Ważne jest, gdzie logika jest implementowana - w jednym miejscu, blisko danych - rzeczywisty język jest tylko szczegółem. PL/SQL kompiluje się do kodu natywnego i uruchamia proces z bazą danych; nie ma architektury o wyższej wydajności niż ta.
  • Nie chcę uczyć się innego języka. Patrzenie przez sekundę jest ogromną czerwoną flagą dla każdego programisty (szczególnie takiego, który proponuje modyfikację produkcji aplikacje, które i tak mogą być w innych językach!) jest wiele do nauczenia się pracy w każdym nowoczesnym środowisku: typowy Java może mieć Eclipse, WebLogic, Maven, Hudson, Anthill, Subversion, i całą masę innych, których musisz się nauczyć przed napisaniem pojedynczego wiersza kodu aplikacji. Znajomość na bardzo wysokim poziomie SP jest prosty w porównaniu, a będzie więcej niż być może specjalistą lub DBA, który również ci pomoże. Nie wspominając o tym, że ulubiony programista Hibernate ma własny język zapytań…

17
Gaius

Czy SQL robi takie rzeczy jak ustawianie logiki i filtrowanie wyników zorientowanych na aplikację? SQL jest wspaniałym językiem manipulacji.

Ponadto, jak wskazano powyżej GBN, kod SQL prawie powszechnie przeżywa kod aplikacji.

Chociaż prawdą jest, że EF, NHibernate, LinqToSql lub cokolwiek innego umożliwi szybsze generowanie kodu, każdy programista wart swojej wydajności wie, że tylko optymalizacja SQL zoptymalizuje pobieranie danych. RDBMS rozumie tylko SQL, więc musisz wszystko przerobić na SQL, zanim wszystko zostanie powiedziane i zrobione. (zakładając, że możemy się zgodzić, że TSQL i PLSQL są nadal SQL)

12
jcolebrand

Jednym oszustwem, o którym ludzie niekoniecznie dyskutują - tutaj zawodowcy zostali wyczerpani - jest koszt.

Procesory na serwerze bazy danych są często najdroższymi procesorami w każdej organizacji, gdy pokrywają koszty licencji oprogramowania. Dlatego przeniesienie logiki biznesowej do warstwy danych jest czymś, co należy robić rozsądnie, niekoniecznie jednakowo.

11
Adam Musch

Oto, gdzie nieuchronnie musi się odbyć spotkanie umysłów, to znaczy umysłów programistów (DV) i DBA. Praca z Business Logic (BL) i przechowywanie takich danych w bazie danych może mieć wpływ, który może gloryfikować lub przerazić jego implementację.

W przypadku niektórych produktów RDBMS istnieją doskonałe biblioteki/narzędzia/interfejsy API dla logiki biznesowej i infrastruktur obiektowych, których można szybko nauczyć się i zastosować w ich aplikacjach. W przypadku innych RDBMS nie istnieją biblioteki/narzędzia/interfejsy API.

W przeszłości aplikacje klienckie tworzyły mostek w BL za pomocą procedur przechowywanych (SP). W przypadku produktów takich jak Oracle i SQL Server zrobiono to wcześniej. Wraz z powstaniem baz danych typu open source, takich jak PostgreSQL i MySQL, użytkownicy korzystający z nich byli narażeni na przełom w zakresie procedur przechowywanych w BL. PostgreSQL dojrzał w tym czasie bardzo szybko, ponieważ zaimplementowano nie tylko procedury składowane, ale także możliwość tworzenia języków klienta. MySQL zasadniczo przestał ewoluować w świecie procedur przechowywanych i przyszedł w formie uproszczonej wersji języka z wieloma ograniczeniami. Tak więc, jeśli chodzi o BL, jesteś całkowicie na łasce MySQL i jego języka procedury składowanej.

Pozostaje tylko jedno pytanie: niezależnie od RDBMS, czy BL powinien znajdować się w całości czy w części w bazie danych?

Pomyśl o deweloperze. Gdy w aplikacji coś pójdzie nie tak, proces debugowania spowoduje, że programista wskoczy i wyskoczy z bazy danych, aby śledzić zmiany danych, które mogą, ale nie muszą być poprawne, sporadycznie. To jest jak kodowanie aplikacji C++ i wywoływanie kodu asemblera w środku. Musisz przełączyć się z kodu źródłowego, klas i struktur na przerwania, rejestry i przesunięcia ORAZ POWRÓT !!! To prowadzi do debugowania na tym samym poziomie.

Deweloperzy mogą być w stanie stworzyć szybką metodę wykonywania BL w połączeniu z konfiguracjami językowymi (flagi kompilatora dla C++, różne ustawienia dla PHP/Python itp.) Za pomocą obiektów biznesowych znajdujących się w pamięci, a nie w bazie danych. Niektórzy próbowali zmostkować tę ideologię w celu szybszego uruchamiania kodu w bazie danych, pisząc biblioteki, w których debugowanie Procedur składowanych i wyzwalaczy jest dobrze zintegrowane z bazą danych i wydaje się niemożliwe do użycia.

Dlatego programista ma za zadanie opracować, debugować i utrzymywać kod źródłowy i BL w dwóch wersjach językowych.

Teraz pomyśl o DBA. DBA chce, aby baza danych była szczupła i miała jak najwięcej znaczeń w dziedzinie procedur przechowywanych. DBA może postrzegać BL jako coś zewnętrznego w stosunku do bazy danych. Jednak gdy SQL wymaga danych potrzebnych do BL, SQL musi być ubogi i wredny.

Teraz na spotkanie umysłów !!!

Kody programisty SP i wykorzystuje metody iteracyjne. DBA patrzy na SP. DBA ustala, że ​​pojedyncza instrukcja SQL może zastąpić iteracyjne metody napisane przez programistę. Deweloper widzi, że instrukcja SQL sugerowana przez DBA wymaga wywoływanie innego kodu związanego z BL lub SQL, który nie jest zgodny z normalnymi planami wykonania instrukcji SQL.

W świetle tego konfiguracja, dostrajanie wydajności i kodowanie SP staje się funkcją głębokości i intensywności danych BL dla pobierania danych. Im większa głębokość i intensywność danych BL, więcej Programiści i DBA muszą znajdować się na tej samej stronie, aby uzyskać dane i moc obliczeniową przekazaną do bazy danych.

WNIOSEK

Sposób wyszukiwania danych powinien zawsze obejmować zarówno obozy programistów, jak i obozy DBA. Należy zawsze udzielać koncesji na to, jakie metody kodowania i paradygmaty wyszukiwania danych mogą ze sobą współpracować, zarówno pod względem szybkości, jak i wydajności. Jeśli przygotowanie danych do obsługi kodu źródłowego odbywa się tylko jeden raz, zanim kod pobierze dane, DBA powinien dyktować użycie lean i średniego SQL. Jeśli BL jest czymś, czego DBA nie jest w zgodzie, stery są wtedy w rękach Dewelopera. Dlatego DBA powinien widzieć siebie i część zespołu projektowego, a nie wyspę dla siebie, podczas gdy Deweloper musi pozwolić DBA dopracować SQL, jeśli to uzasadnia.

7
RolandoMySQLDBA

To miłe pytanie zadać na stronie internetowej pełnej DBA. Mamy nadzieję, że większość odpowiedzi będzie „pro” w kierunku utrzymania bazy danych w stanie ACID, a tym samym utrzymania logiki biznesowej w bazie danych. : -)

Moim zdaniem, powinieneś zaimplementować logikę biznesową zarówno w swoich aplikacjach, jak i bazach danych. Takie podejście będzie kosztowało więcej czasu i pieniędzy, ale myślę, że w rezultacie będzie miało jakościowe lepsze rozwiązanie biznesowe.

4
Ruud van de Beeten

Jak powiedział Adam Musch powyżej, należy wziąć pod uwagę więcej możliwości. Użycie procesora. Zużycie pamięci.

Blokuj oczywiście złe rzeczy przed dostaniem się do bazy danych.

  • Zlikwiduj adresy e-mail, które nie są zgodne w jakiś podstawowy sposób.
  • Sprawdź długości

Kiedy się zagłębisz, wtedy trzeba podjąć decyzję. Serwer DB jest bardzo drogim miejscem do robienia rzeczy, które klient mógłby zrobić z łatwością. przykład: formatowanie danych, formatowanie dat, składanie ciągów itp. po stronie klienta.

Czy robisz matematykę/przetwarzanie u klienta czy na serwerze DB? Dla mnie zależy to od złożoności i liczby zaangażowanych zapisów. Logika biznesowa powinna być naprawdę wykonywana w samej bazie danych, aby wszystko było traktowane w ten sam sposób.
Naprawdę powinieneś utworzyć interfejs API widoków do odczytu i zapisywania procesów do zapisywania danych do bazy danych, aby zaoszczędzić sobie bólu głowy w przyszłości.

Wykorzystaj mocne strony każdego końca na swoją korzyść.

2
Matt M