Jakie są argumenty przeciwko lub za umieszczeniem logiki aplikacji w warstwie bazy danych? [Zamknięte]

Większość twórców oprogramowania chce zachować logikę aplikacji w warstwie aplikacji, i prawdopodobnie wydaje nam się, że utrzymujemy ją tutaj. 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 lub nie powinno być w porządku w implementacji w warstwie bazy danych?

Edytuj To pytanie jest również omówione na stronie dba.se , z perspektywy DBA. Ponieważ programmers.se i dba.se mają różnych odbiorców i stronniczości, przyszli czytelnicy mogą chcieć przejrzeć oba zestawy odpowiedzi, zanim zdecydują, co będzie dla nich najlepsze.

Z góry mojej głowy, zalety logiki w warstwie aplikacji.

1. Testability . To właściwie powinien być wystarczający powód.
2. Lepsza struktura kodu . Bardzo trudno jest przestrzegać właściwej architektury OO za pomocą SQL. Zwykle ułatwia to także utrzymanie kodu.
3. Łatwiej kodować . Ze względu na wszystkie różne funkcje językowe dostępne w dowolnym języku, którego używasz, kodowanie w warstwie aplikacji jest zwykle łatwiejsze.
4. Ponowne użycie kodu . O wiele łatwiej jest współdzielić kod z bibliotekami niż współdzielić kod z bazy danych.

Chociaż można używać kontroli wersji z procedurami przechowywanymi (na przykład narzędzia bazy danych Redgate integrują się z TFS), nie zawsze jest tak proste, jak w przypadku kodu aplikacji.

Moja domyślna pozycja jest taka, że ​​logika powinna być trzymana poza warstwą bazy danych, jednak są chwile, kiedy bardziej efektywne byłoby zaimplementowanie logiki w bazie danych. W takim przypadku musisz upewnić się, że możesz śledzić zmiany w tym kodzie.

W jednej firmie, w której pracowałem, było wiele biurokracji związanej z wydaniem kodu do produkcji i zaangażowanie DBA w wydanie kodu zawsze było koszmarem. Zawsze umieszczamy logikę w warstwie aplikacji, aby wyeliminować konieczność radzenia sobie z DBA, z którymi trudno było pracować. Jest to całkowicie kulawy powód, ale wywodzący się z konieczności.

Umieszczenie logiki aplikacji w DB wydaje mi się złym pomysłem. OTOH umieszczenie logiki w DB, która jest szczególnie częścią utrzymywania stanu DB (np. Wyzwalacze / sproki do aktualizacji zdenormalizowanych tabel) jest zupełnie inną propozycją.

Alternatywnie można to określić jako: istnieją dobre argumenty za odłożeniem logiki potrzebnej do wyodrębnienia, w jaki sposób baza danych naprawdę działa, od tego, jak chcesz, aby wyglądała w bazie danych.

Po przeczytaniu obu pytań wydaje mi się, że wszyscy przeoczyliśmy jeden punkt krytyczny. Prawidłowa odpowiedź może zależeć od rodzaju tworzonego oprogramowania. Grupa DBA w dużej mierze pracuje nad krytycznymi dla biznesu systemami oprogramowania dla przedsiębiorstw, a ich odpowiedzi odzwierciedlają to, co jest konieczne w tym świecie. Istnieje ogromna różnica w tym, co jest potrzebne do tego rodzaju aplikacji, niż w przypadku następnej aplikacji „Facebook”. To nic wielkiego, jeśli stracisz kilka słupków ściennych, to jeśli stracisz kilka zamówień lub innych transakcji finansowych.

Ludzie, którzy pracują w świecie COTS (Commercial Off-the Shelf), zwykle muszą być agnostyczni wobec baz danych ze względów sprzedażowych i chcą wszystkiego w zgodnym kodzie, aby utrudnić inżynierię wsteczną i wymienić ich produkt na domowy. Aplikacje Enterprise opracowane i utrzymywane we własnym zakresie prawie nigdy nie będą musiały zmieniać zaplecza bazy danych, z wyjątkiem aktualizacji.

Aplikacje korporacyjne są również tymi, które zwykle mają dane wejściowe z wielu miejsc, a baza danych jest jedyną wspólną cechą. System, w którym pracuję, ma dostęp do setek różnych aplikacji, a także setki importów danych klientów, eksport danych do klientów i hurtowni danych oraz korzysta z wielu systemów raportowania. Kod, który działa dobrze podczas dodawania jednego rekordu, nie działa, gdy muszę zaimportować 20 000 000. Zostaliśmy zmuszeni do użycia warstwy aplikacji raz, ponieważ tam była logika i musieliśmy zatrzymać proces 18 godzin później niedokończony. Logika, która powinna mieć zastosowanie do wszystkich rekordów danych w tabeli, musi znajdować się w bazie danych, gdy nie można mieć jednej warstwy danych, z której wszyscy korzystają.

I odwrotnie, gdy tylko jedna aplikacja zużyje dane, a dane nie są siłą napędową Twojej firmy lub są empiryczne, zasady są różne i umieszczenie całej logiki w aplikacji ma większy sens.

Długawy. patrz Podsumowanie na dole.

RDBMS

RDBMS oznacza system zarządzania relacyjnymi bazami danych. Jest to system do zarządzania relacyjną bazą danych. Dane są tam przechowywane. Dane. Nie mówi logiki biznesowej.

Proces biznesowy

Co tak naprawdę oznacza logika biznesowa? Dla mnie to logiczny opis procesów biznesowych.

Procesy to takie działania biznesowe, które występują regularnie, na tyle, że nie są już ad hoc. Są one różne dla każdej firmy.

Pozwól mi założyć moją czapkę biznesową i wyjaśnić, co oznacza tutaj biznes. Dla niektórych może to być zaskoczeniem.

Biznes

Biznes to suma działań przeprowadzonych w celu osiągnięcia wartości, a dokładniej wartości, którą można handlować. Może to oznaczać robienie kombajnów, kanapek z tuńczykiem lub świadczenie usług bankowych. W większości krajów świata, nawet w systemach niekapitalistycznych, ludzie lubią uzyskiwać jak najwięcej za swoje pieniądze, a zatem istnieje konkurencja między różnymi dostawcami tych cennych towarów i usług. Konkurencja zasadniczo zależy od ceny, jakości i dostępności.

Szybki objazd: potrzebujesz 40 milionów nitów w ciągu 2 dni, nie zamawiasz od jakiegoś faceta w Internecie z kontem PayPal, bez względu na to, o ile tańsza jest jego cena niż u zwykłego sprzedawcy.

Wiedza o procesie

Jak można sobie wyobrazić, procesy związane z tworzeniem tej „wartości” przeważają w głowach wykonawczych. Niektóre z nich są zapisywane na papierze i wykorzystywane jako zasady i procedury firmy. Niektóre z nich żyją w głowach radców prawnych. Wiele z nich żyje w głowach ludzi kierujących oddziałami, działami, zespołami i kierujących maszynami, kasami, piekarnikami i ciężarówkami. Niewielki ich podzbiór obniża wymagania biznesowe dotyczące oprogramowania, a jeszcze mniejszy podzbiór jest dokładny do czasu jego wdrożenia w systemach komputerowych.

Ostatecznie logika biznesowa, którą widzisz w kodzie, nie jest tym, który prowadzi biznes, tylko tym, który uruchamia aplikację dla biznesu. Rzeczywiste mózgi w rzeczywistych ludziach przechodzą rzeczywiste procesy biznesowe i nie mają problemu ze zrozumieniem, że proces w ich mózgu jest dokładniejszy niż proces w komputerze. Nawiasem mówiąc, prawdopodobnie nie mógłbyś prowadzić firmy, gdyby wszystko, co miałeś, to zasady i procedury większości korporacji. Bardzo często są one rażąco niedokładne, pomimo wysiłków Herkulesa.

Tak więc ostatecznie logika aplikacji jest zakodowana w oprogramowaniu. I ludzie chcą umieścić to w bazie danych, ponieważ dostawcy systemów zarządzania bazą danych wysunęli wielkie roszczenia.

Logika aplikacji

Mówię nie. Mówię, że logika aplikacji pozostaje wewnątrz aplikacji. Dane trafiają do bazy danych w bardzo znormalizowany sposób, a następnie trafiają do bazy danych ETL w celu raportowania, wiercenia, zwijania, obracania i dzielenia.

Dane

Mówię również, że dane przeżywają dłużej niż aplikacja, więc wysiłki związane z normalizacją danych nie powinny być specyficzne dla aplikacji, a nawet specyficzne dla biznesu, ale raczej powinny być ogólne. Czy przechowujesz kody stanów? Powinieneś używać INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html), ponieważ jest przenośny dla różnych firm. Ułatwia to także wielu aplikacjom manipulowanie danymi.

NoSQL?

Jeśli traktujesz bazę danych jako część kodu aplikacji, od układu tabel do wyzwalaczy, procedur przechowywanych i formatów danych, zasadniczo używasz korporacyjnej bazy danych jako uwielbionego BerkleyDB, który jest uwielbioną płaską strukturą plików, który jest tak naprawdę tylko utrwalonymi listami. To jest właśnie to, co robi NoSQL: powrót do korzeni, ale robienie tego w wieloprocesowy, uparty, odporny na awarie.

Aktualny kod

Nie, musisz traktować bazę danych jako wspólne repozytorium danych dla wielu aplikacji, zarówno obecnych, jak i przyszłych. Teraz dochodzimy do sedna mojej argumentacji. Procesy biznesowe zmieniają się wraz z kaprysami rynku, polityki i mody. Bardzo często zmieniają się szybciej, niż koderowie potrafią zarządzać językami klasy informatycznej (Java, C #, C ++ itp.) I kończą pisanie w VBA w arkuszach kalkulacyjnych Excela w dziale księgowości lub marketingu. (I tylko jeśli nie można tego wyrazić w fantazyjnych widokach ...)

Degradacja bazy danych

Dane niewiele się zmieniają, jeśli są dobrze zorganizowane. Logika biznesowa zmienia się bardzo szybko. Umieszczenie logiki biznesowej w bazie danych powoduje, że baza danych staje się mniej wartościowa, ponieważ wcześniej stanie się przestarzała i niedokładna.

Podsumowanie

Dane muszą przeżyć aplikację, ponieważ procesy biznesowe w niej działają, a procesy biznesowe zmieniają się znacznie częściej. Zawarcie logiki biznesowej w bazie danych jest niekorzystne ze względu na jej długowieczność i ogólną wartość.

Zastrzeżenie

Zrobiłem część dba-dingu i przeczytałem odpowiedzi na dba.se, ale szczerze mówiąc, chodzi o problemy z integralnością danych i wydajnością. Całkowicie zgadzam się, że osoby, które dotykają danych korporacyjnych, powinny wiedzieć, co robią, czy to dba, programista, czy starszy analityk SAS z dostępem do odczytu / zapisu.

Zauważyłem również, że polecają programistom znać SQL. Zgadzam się. Jest to język programowania komputerowego, więc nie rozumiem, dlaczego programiści nie chcieli go znać.

Później, po przemyśleniu

Myślę, że podstawą jest stworzenie interfejsu API i zarządzanie tym przepływem danych tam iz powrotem. Jeśli nie możesz zezwolić aplikacjom na bezpośrednie łączenie się z tabelami, przynajmniej możesz sprawić, że mechanizm dostępu będzie w nowoczesnych językach.

Ryzykując, że zabrzmi to dramatycznie, jestem naprawdę przerażony ideą logiki aplikacji w bazie danych. Wiele odpowiedzi tutaj koncentruje się na zaletach tworzenia oprogramowania, więc dla zwięzłości zamierzam skupić się na korzyściach wynikających z podziału odpowiedzialności.

Bazy danych zapewniają skuteczny sposób przechowywania i uzyskiwania dostępu do informacji przy jednoczesnym minimalizowaniu zbędnych danych i tworzeniu logicznych relacji w danych. Chociaż logika bazy danych może być w stanie zaimplementować logikę biznesową na poziomie produkcyjnym, moja osobista opinia jest taka, że ​​baza danych powinna być możliwie jak najbardziej niezależna od aplikacji, aby zapewnić, że dane mogą być skutecznie wykorzystywane przez wiele aplikacji podczas korzystania z odpowiednich mocnych stron bazy danych silnik a mocne strony języka implementacji aplikacji.

Jeden użytkownik na wymianie stosu DBA stwierdził, że ...

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, żeby to ująć.

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.

... Następnie jego przekonanie, że świadczy to o naruszeniu zasady OSUSZANIA.

Uważam, że nie jest to powtórzenie logiki biznesowej, ale jest to prawdopodobnie doskonały przykład elastyczności zapewnianej przez wyraźny podział obowiązków między warstwą biznesową a warstwą danych.

Ich baza danych OLTB od dziesięcioleci niezawodnie i skutecznie dostarcza dane do ponad 25 aplikacji! To wspaniale! (Tak trzymać!)

Mogę tylko założyć, że dane są wystarczająco agnostyczne, aby zapewnić zawartość dla wielu różnych aplikacji. Coś, co byłoby w dużej mierze niemożliwe, gdyby ci programiści próbowali zhakować coś razem przy użyciu logiki bazy danych.

Jak wskazały inne odpowiedzi, istnieje wiele innych powodów, aby nie wdrażać programu w bazie danych. Jestem pewien, że to zadziała, ale najbardziej prawdopodobnym rezultatem byłyby dziesięciolecia żalu, a nie dziesięciolecia stabilności.

Aplikacje agnostyczne z bazami danych wymagają logiki z baz danych. Bardzo trudno jest zbudować i utrzymywać kod dla wielu różnych dostawców baz danych.

Dobry rozwój zapewni równowagę między potrzebą integralności bazy danych a szybkością poprzez umieszczenie części logiki w bazie danych, a większość w aplikacji.

Czy to samo zapytanie będzie używane wielokrotnie w wielu aplikacjach, być może należy ono do procedury składowanej.

Zapewnienie, że pola prowadzenia domu są ustawione, gdy wiersz jest wstawiany i aktualizowany, jest obowiązkiem DBA. Spust zostanie użyty.

Z drugiej strony, jeśli mam logikę biznesową, musi być w aplikacji. Powinien, w miarę możliwości, wywoływać procedury składowane, które zwrócą pożądany, przefiltrowany zestaw rekordów z dokładną liczbą wymaganych pól. Nie więcej, nie mniej.

To kwestia komunikacji między zespołami oraz rozpoznanie zalet i wad każdej z możliwości.

Moja opinia brzmi: nie rób logiki aplikacji zbyt głęboko w DB.

Niektóre systemy handlowe umożliwiają rozszerzenie istniejących funkcji za pomocą skryptów umieszczonych w bazie danych. Moje doświadczenia z tym są raczej negatywne, przynajmniej w środowisku wielu użytkowników.

Umieściłbyś logikę w bazie danych, ponieważ chciałbyś mieć możliwość łatwej modyfikacji tej logiki.

• Jak przeprowadziłbyś kontrolę wersji?
  • Jaka jest historia kodu? Jakie były zmiany? Przez kogo?
  • Jak radzisz sobie ze zmianami w tych samych fragmentach kodu?
• Jak zidentyfikowałbyś i zagwarantowałeś spójny stan kodu?

Możesz to wyśledzić w dodatkowym VCS opartym na plikach, ale jaka jest korzyść z bazy danych?

Większość aplikacji musi mieć jakiś sposób na zapewnienie integracji. Idealnie byłoby mieć pełny interfejs API, usługę internetową lub przynajmniej udostępnić niektóre obiekty bazy danych zawierające logikę biznesową. Każdy nie ma czasu / zasobów, aby zbudować API, więc musisz iść na kompromis.