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

UWAGA Odbiorcy programmers.se i dba.se są różni i będą mieli różne punkty widzenia, więc w tym przypadku uważam, że warto powielić Jakie są argumenty przeciwko lub za umieszczeniem logiki aplikacji 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ść twórców oprogramowania chce zachować logikę aplikacji w warstwie aplikacji i prawdopodobnie wydaje nam się 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 w implementacji w warstwie bazy danych?

Uwaga: nie jestem OP dla tego pytania, ale nie zmieniłem oryginalnego brzmienia.

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 z 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ć jednej na sekundę

Chcę całej logiki, która musi mieć zastosowanie do wszystkich użytkowników i wszystkich aplikacji 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 bazy danych OLTP. Niektóre z tych programów zostały wprowadzone do produkcji w latach siedemdziesiątych.

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

Jakie są szanse?

Czy to nie jest jedno największe na świecie „ nie powtarzaj się ”?

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 kontroli zmienia się w taki sam sposób, jak kontroluje się aktywność bazy danych - poprzez rejestrowanie
• Znacząco ulepszone bezpieczeństwo i drobiazgowa 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 niestandardowych raportów - 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.

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

Swoją odpowiedź zapisałem na swoim blogu . Mój wniosek jest taki, że robienie tego w aplikacji po prostu nie jest skalowane, jeśli weźmiesz pod uwagę cały cykl ż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 uszkodzona aplikacja wymaga modyfikacji, nie wszystkie z nich (a większość mechanizmów SP / bazy danych pozwoli na wyjątek 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ę:

• Kontrola wersji kodu SP wdrożonego w bazie danych jest trudna. Nie sądzę, żeby było to bardziej prawdziwe niż stwierdzenie, że trudno jest kontrolować wersję kodu Java wdrożonego na serwerze aplikacji, co oznacza, że ​​wcale nie jest trudny, to powszechne. W Ruby-land całe książki są pisane właśnie o tym, jak wprowadzić kod ze środowiska programistycznego do produkcji, czymś, z czym nie zmaga się żadna inna społeczność językowa. Jednak wersja kontrolująca procedurę przechowywaną jest najwyraźniej zbyt trudna.
• Procedury przechowywane są trudne do przetestowania. To 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. Więc to jest jeden zestaw typowych testów jednostkowych, których możesz potrzebować w Ruby, wyeliminowany z nietoperza. Testowanie kodu OO wymaga kpiny w celu wymuszenia na obiekcie wprowadzenia stanu wewnętrznego wymaganego do przedstawienia scenariusza testowego - czym różni się konfiguracja danych testowych? Istnieje producent TAP dla PL / SQL i innych narzędzi oprócz. Istnieją również debugery i profile.
• Język procedury składowanej nie jest językiem w pełni funkcjonalnym. Nie próbujemy pisać całej aplikacji tylko w procedurach przechowywanych! Większość dedykowanych języków SP ma wszystkie nowoczesne konstrukcje, których można się spodziewać, a przynajmniej w Oracle można używać procedur przechowywanych Java ze wszystkimi funkcjami językowymi, które znają programiści OO, lub procedur zewnętrznych w dowolnym języku. Liczy się to, gdzie logika jest zaimplementowana - 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 tam architektury o wyższej wydajności.
• Nie chcę uczyć się innego języka. Przez sekundę jest to ogromna czerwona flaga dla każdego programisty (zwłaszcza takiego, który proponuje modyfikowanie aplikacji produkcyjnych, które i tak mogą być w innych językach!) Jest wiele do nauczenia się pracy w każdym nowoczesnym środowisku: typowy sklep Java może mieć Eclipse , WebLogic, Maven, Hudson, Anthill, Subversion i cała masa innych, których musisz się nauczyć przed napisaniem jednego wiersza kodu aplikacji. W porównaniu do nich praktyczna znajomość języka SP na bardzo wysokim poziomie jest łatwa, a specjalista lub DBA będzie w stanie Ci pomóc. Nie wspominając o tym, że ulubiony programista Hibernacja ma własny język zapytań…

…

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

Dodatkowo, jak wskazano powyżej GBN, kod SQL prawie powszechnie przeżyje kod aplikacji.

Chociaż prawdą jest, że EF, NHibernate, LinqToSql lub cokolwiek innego pozwoli ci szybciej wygenerować kod, 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)

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.

Oto, gdzie nieuchronnie musi się odbyć spotkanie umysłów, to znaczy umysłów Deweloperó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śnie. 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ą być poprawne lub nie, co jakiś czas. 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 debugowanie 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 przełączyć tę ideologię na szybsze uruchamianie 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 jak najwięcej znaczyła 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 !!!

Deweloper koduje SP i stosuje 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łania 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 stają się funkcją głębokości i intensywności danych BL dla pobierania danych. Im większa głębokość i intensywność danych, tym więcej programistów i DBA musi 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.

To miłe pytanie, które można 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.

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 łatwo zrobić. przykład: formatowanie danych, formatowanie dat, składanie ciągów itp. po stronie klienta.

Czy wykonujesz 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 samym DB, aby wszystko było traktowane w ten sam sposób.
Naprawdę powinieneś utworzyć interfejs API widoków do odczytu i zapisywania procesów, aby zapisywać dane do bazy danych, aby w przyszłości zaoszczędzić sobie bólu głowy.

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