Dlaczego funkcje bazy danych są ignorowane, a zamiast tego wymyślane na nowo w środkowej warstwie?

Jakie są główne powody ( oprócz „niezależności bazy danych” ), dla których większość dzisiejszych projektów informatycznych wydaje się ignorować bogactwo funkcji dostępnych w nowoczesnych silnikach baz danych, takich jak Oracle 11g i SQL Server 2008?

Lub, zapożyczając z bloga Deklaracji Helsińskiej, który przedstawia to w ten sposób:

W ciągu ostatnich dwudziestu lat obserwujemy, że funkcjonalność (cechy), które są dostępne dla nas w DBMS, gwałtownie wzrosła. Te funkcje umożliwiły nam tworzenie aplikacji bazodanowych. I to właśnie zaczęliśmy wszyscy w rozkwitających latach dziewięćdziesiątych.

Ale potem, u zarania nowego tysiąclecia, coś się wydarzyło. I to w tajemniczy sposób sprawiło, że rola DBMS w projekcie aplikacji bazodanowej stała się nieistotna. (...) Od nowego tysiąclecia wypychamy całą logikę aplikacji z DBMS na serwery średniej warstwy. Funkcjonalność rzeczy zaimplementowanych poza DBMS eksplodowała, a bogaty w funkcje DBMS jest używany tylko do przechowywania wierszy.

Mówimy o takich rzeczach jak

• Procedury składowane używane jako interfejsy API danych (dla bezpieczeństwa i uniknięcia nadmiernego ruchu sieciowego)
• Zmaterializowane widoki
• Wyzwalacze zamiast
• Zapytania hierarchiczne (połącz przez)
• Geografia (typy danych przestrzennych)
• Analityka (lead, lag, rollup, cube itp.)
• Wirtualna prywatna baza danych (VPD)
• Inspekcja na poziomie bazy danych
• Zapytania flashback
• Generowanie XML i transformacja XSL w bazie danych
• Wywołania HTTP z bazy danych
• Harmonogram zadań w tle

Dlaczego te funkcje nie są używane? Dlaczego większość programistów Java, .NET i PHP trzyma się podejścia „SELECT * FROM mytable”?

Ponieważ procedury składowane:

• dodać kolejny język programowania, zwiększając złożoność i potencjalnie zbędny kod (logika napisana w obu językach);
• ogólnie mają gorsze możliwości narzędziowe, monitorowania i debugowania niż PHP, C #, Java, Python itp .;
• są generalnie mniej sprawne niż większość języków średniego poziomu;
• mają tę przewagę tylko w przypadku transformacji danych o dużej objętości (w której unika się wymiany danych z serwera), co zwykle stanowi minimum rzeczywistego wykorzystania.

To powiedziawszy, jest to powszechna metodologia w aplikacjach C # ASP.NET.

Jak to ujął Jeff Atwood, procedury składowane są językiem asemblera baz danych i ludzie nie mają tendencji do kodowania w asemblerze, chyba że tego potrzebują.

Często korzystałem ze zmaterializowanych widoków, a czasami korzystałem z CONNECT BY w Oracle, z których żadna, jak sądzę, nie istnieje w MySQL.

Zwykle nie używam XML / XSLT w bazie danych, ponieważ cóż, oznacza to, że używam XML i XSLT.

Jeśli chodzi o struktury danych geograficznych lub przestrzennych, prawdopodobnie jest tak, że trudno je po prostu „odebrać”. To dość specjalistyczny obszar. Przeczytałem podręcznik MySQL na temat struktur danych przestrzennych i jestem pewien, że ma to sens dla kogoś z dużym doświadczeniem GIS, ale dla mnie i moich ograniczonych potrzeb (które zwykle dotyczą zaznaczania szerokości / długości geograficznej punktu) po prostu nie ma Wydaje się, że nie warto poświęcić czasu, aby to rozgryźć.

Inną kwestią jest to, że jeśli wyjdziesz poza ANSI SQL (dużo), to po prostu związałeś się nieco z konkretnym dostawcą bazy danych i prawdopodobnie z określoną wersją. Z tego powodu twórcy aplikacji często traktują swoje bazy danych w najniższym wspólnym mianowniku, co oznacza traktowanie ich jako wysypiska dla danych relacyjnych.

Ponieważ programiści nie wiedzą o SQL. Opierają się na DDL i DML generowanym przez narzędzia takie jak Hibernate i konstrukcje na poziomie języka, takie jak adnotacje JPA. Deweloperów nie obchodzi, czy są one okropnie nieefektywne, ponieważ są na szczęście ukryte przez normalne poziomy dzienników i ponieważ administratorzy baz danych nie są częścią zespołów programistycznych.

Dlatego lubię narzędzia iBATIS . Umożliwiają pisanie i rozumienie języka SQL, w tym specyficznych funkcji DBMS.

Myślę, że jednym z powodów jest strach przed blokadą sprzedawcy.

Nie mówi się o tym zbyt często, ale korzyści wynikające z używania funkcji specyficznych dla dostawcy należy porównać z kosztami. Głównie koszt konieczności przepisywania części, które opierają się na funkcjach specyficznych dla dostawcy dla każdej bazy danych, którą chcesz obsługiwać. Wdrażanie czegoś w sposób ogólny, a dostawca zapewnia lepszy, wiąże się również z kosztami wydajności.

Podam ten przykład: można by uznać „blokadę” SQL Server za bardziej akceptowalną, gdy uświadomimy sobie wszystkie rzeczy, które Analysis Services, Reporting Services itd. Mogą zrobić dla waszej aplikacji. W przypadku dużych komercyjnych systemów baz danych nie należy brać pod uwagę „tylko” silnika bazy danych SQL.

„Dlaczego funkcje bazy danych są ignorowane”.

Ponieważ wielu tak zwanych programistów nie ma pojęcia o zarządzaniu danymi, a co gorsza, zupełnie nie wiedzą też o swojej ignorancji. „Niewykwalifikowany i nieświadomy tego”, któremu to dzwoni.

Jeśli oprogramowanie działa na sprzęcie klienta, wszelkie zmiany w bazie danych (nowe procedury składowane, zaktualizowane widoki itp.) Będą wymagały uprawnień administratora bazy danych. Prawie zawsze jest to problem dla klientów. Zaangażowanie grupy DB komplikuje wszelkie aktualizacje, które musisz wykonać. Przedstawiono tutaj wiele wspaniałych powodów, ale jest to jedyny, którego potrzebuję, aby uniknąć umieszczania kodu w bazie danych jak zarazy.

Myślę, że jednym z powodów jest strach przed blokadą sprzedawcy. Te funkcje DBMS nie są ustandaryzowane - na przykład procedury składowane są bardzo specyficzne dla bazy danych, a jeśli zaimplementowałeś rzeczy przy użyciu procedur składowanych (zamiast, powiedzmy, usług internetowych udostępnianych za pośrednictwem warstwy środkowej), to na zawsze utkniesz z pierwszym wybranym DBMS , (to znaczy, chyba że chcesz poświęcić czas / pieniądze na ponowne wdrożenie go w innym DBMS, jeśli chcesz zmienić DBMS).

MySQL.

Kiedy aplikacje internetowe eksplodowały pod koniec lat 90. i na początku 2000 r., MySQL był w wersji 3.3 lub 4.0 i nie obsługiwał niczego poza prostymi SELECT. Był jednak darmowy i zainstalowany w większości dystrybucji Linuksa. W rezultacie pokolenie programistów nie nauczyło się o bazach danych i nie wie, jak z nich korzystać.

Nawet teraz, gdy MySQL jest w wersji 5.1 i obsługuje większość funkcji systemu komercyjnego, te same okropne stare blogi i artykuły są używane jako szablony, gdy uruchamiany jest nowy projekt LAMP, a MySQL jest wdrażany z tabelami MyISAM i funkcjonalnością ery 3.3 .

SQL zawodzi z tego samego powodu, co np. Haskell. Miarą, która decyduje o sukcesie językowym, nie jest czystość, nie łatwość interpretacji przez komputery, ale to, jak trudno jest utrzymać napisane w nim programy.

Zwykłym śmiertelnikom zawodzi nawet najprostszy język. Być może 1 na 10 osób posiada umiejętności posługiwania się prostym językiem, takim jak C #. Ale z tych 10% tylko 1 na 10 lub 1% ludzi potrafi efektywnie używać języków takich jak SQL czy Haskell.

Teraz SQL jako język jest niekompletny, w tym sensie, że niewiele rzeczy można zrobić za pomocą samego SQL. Zawsze będziesz potrzebować innego języka. Jaką rolę pozostawia to SQLowi? Programiści zrozumieją zalety ACID w porównaniu z przechowywaniem plików płaskich, ale poza tym bazy danych naprawdę nie mają nic do zaoferowania.

Drugim problemem jest to, że SQL w rzeczywistości nie jest zbyt kompatybilny z wersjonowaniem źródeł. SQL wydaje się być naprawdę zbudowany na założeniu, że robisz to dobrze za pierwszym razem. Tak więc nie jest to tylko nieodpowiednie dla programistów, ale także słabo pasuje do procesu tworzenia.

Łatwiej jest naprawić / ponownie wdrożyć warstwę środkową niż DBMS.

To prawdopodobnie zależy od Twojej architektury, ale to jest nasz powód. Połącz to z faktem, że mamy jednego administratora danych, który jest bardziej zajęty i (prawdopodobnie) zarabia więcej niż nasi programiści. Wszyscy programiści znają SQL, a niektórzy z nich są częściowo zorientowani w języku proceduralnym. Gdyby pojawił się naprawdę skomplikowany problem produkcyjny, programiści mogliby łatwiej i szybciej pracować na środkowej warstwie niż na bazie danych, niezależnie od tego, czy architektura byłaby lepsza w jedną czy drugą stronę.

Spotkałem sporo osób, które po prostu nie zdawały sobie sprawy, że takie funkcje istnieją - wycięli zęby we wczesnych dniach MySQL i nigdy tak naprawdę nie używali niczego innego i nie nadążają a nawet rozwój nowych tabel pamięci masowej w mySQL. Albo nauczyli się baz danych w szkole i nigdy nie wrócili, aby zobaczyć wszystkie rzeczy, które przegapili.

Uczą się minimum SQL, aby sobie poradzić, i nie zdają sobie sprawy ze wszystkich różnych rozszerzeń oferowanych przez różne systemy RDBMS.

W jednym projekcie chciałbym mieć zmaterializowane widoki ... ale używam Postgres. Chciałbym użyć typów danych przestrzennych w innym projekcie, ale będę musiał zrobić hack lub zmienić bazy danych, aby poradzić sobie z twierdzeniem MySQL, że nie są zerowe. Musiałem nawet wymyślić, jak wyłączyć spójność transakcyjną Oracle, aby poradzić sobie z długo działającymi zapytaniami na OLTP, które nie byłyby problemem w MySQL.

Mogę normalnie kodować wokół niedociągnięć bazy danych dla danego problemu, ale część problemu polega na wybraniu odpowiedniego narzędzia do pracy - w bieżącym projekcie zmarnowaliśmy wiele miesięcy na replikację danych, używając Postgres i zdecydowali się na Slony-1, zanim faktycznie dowiedzieli się wszystkiego, co będziemy replikować.

... Postrzegam to pytanie jako pytanie „dlaczego więcej osób nie używa funkcji x w języku y ” - jeśli nie są ekspertami w języku y , mogą nie wiedzieć, że funkcja x istnieje.

(i nie traktuj tego jako wsparcia w uzyskaniu certyfikatu DBA ... Znam kilku administratorów baz danych Oracle, którzy nie potrafili zaprogramować wyjścia z mokrego worka; Przeszedłem wszystkie kursy w dniach 8i, ale odmówiłem przystąpienia do testów, ponieważ nie chciałem być wrzucony do tej grupy)

Myślę, że największym powodem, który przyćmiewa całą resztę, jest to, że systemy relacyjnych baz danych stają się dramatycznie ważniejsze, gdy wiele aplikacji współdzieli te same dane. Słynny artykuł Codda nosi tytuł „Relacyjny model danych dla dużych banków danych współdzielonych ” (wyróżnienie moje).

Ludzie mają skłonność do myślenia, że ​​aplikacja, którą teraz piszą, zawsze będzie kontrolowana przez ich zespół; i że zawsze zaspokoi wszystkie potrzeby osób zainteresowanych danymi generowanymi przez aplikację. Gdyby pojawiła się nowa potrzeba, byłoby to zaspokojone poprzez dodanie nowej funkcji do istniejącej aplikacji, a nie tworzenie nowej aplikacji.

Ale w wielu przypadkach (oczywiście nie we wszystkich; każda sytuacja jest inna) ten model rozwoju nie działa zbyt dobrze w dłuższej perspektywie. Ponieważ dane generowane przez aplikację gromadzą się i stają się coraz ważniejsze dla firmy, różne osoby będą miały ciekawe pomysły dotyczące sposobu ich wykorzystania. Kiedy tak się dzieje, jeśli nie masz systemu zarządzania relacyjnymi bazami danych, czeka Cię duże wyzwanie.

Skalowalność. Im więcej pracy poświęcisz serwerowi bazy danych, tym większe staje się wąskie gardło. Bardziej skalowalne jest posiadanie całej farmy serwerów aplikacji z równoważeniem obciążenia, które przetwarzają dane i po prostu używają bazy danych jako magazynu trwałego.

Byłem w zbyt wielu sytuacjach, w których polityka korporacyjna („nie mamy dostępu do SQL Servera, więc pozwólmy zainstalować mniej potężny system DBMS, taki jak Access, aby przetwarzać miliony wierszy i połączyć go z milionami wierszy w innej tabeli i pozwolić zautomatyzować ten import .. ”) lub nawet kwestie techniczne, które mogą się zdarzyć („ Wiem, że Access może obsłużyć taką ilość danych, a nawet jeśli tak się nie stanie, możemy podzielić MDB na kilka MDB i odwołać się do nich… ”)

UGH. Polityka korporacyjna i polityka techniczna, a nawet ignorancja uniemożliwiły mi korzystanie z wielu funkcji.

Inny przykład - nie widzę powodu, aby nie używać procedur składowanych w 100% sklepie Microsoft, gdzie SQL Server jest preferowanym systemem DBMS. Ale ponieważ informatyk, który ostatecznie miał być właścicielem rozwiązania, był „lekki” na SP, musiałem uciekać się do innych środków. Chodzi mi o to, że jest doskonały przykład, dlaczego niektórzy z tych „funkcji” zostali zignorowani przez nich w ich sklepie.

Znam inny sklep, który nadal używa DOS Foxpro 2, ponieważ ich jedyny informatyk napisał w ten sposób istniejący system i tak będą opracowywane wszystkie nowe rzeczy. Czemu? Nie możemy iść z duchem czasu? Wielu ludzi zajmujących się marketingiem ma kilka otwartych komunikatów DOS na raz, z uruchomionymi w nich „zadaniami” Foxpro, tworzącymi najbardziej brzydkie raporty, jakie kiedykolwiek widziałem. Ale to działa - dam im to. To działa - mają 12 milionów wierszy w głównym stole i ponad 50 innych tabel, które „dołączają” do tego głównego stołu (oczywiście nie wszystkie 50 na raz), ale człowieku ... to już dawno po 1991! Nie chcą nawet omawiać jednej pozycji z listy wypunktowanej, którą podałeś w swoim pytaniu.

Myślę, że właśnie takie rzeczy.

Powiedziałbym, że największym powodem jest to, że większość ludzi o nich nie wie. Gdy ktoś znajdzie rozwiązanie problemu, staje się to domyślnym rozwiązaniem podobnych. Tabela SELECT * FROM od dawna działa dla wielu ludzi, więc nie zawracają sobie głowy szukaniem nowych podejść do starych problemów.

Innym powodem jest to, że czasami napisanie tego w kodzie jest znacznie łatwiejsze niż użycie bazy danych. To ten sam pomysł, co rolowanie własnego a kupowanie gotowego komponentu. Korzystanie z gotowej funkcji może rozwiązać Twoje problemy wiele razy, ale od czasu do czasu musisz zrobić coś, co wykracza poza możliwości tego, co mogą wykonać wstępnie napisane komponenty.

Ładne pytanie i dobra dyskusja.

Innym sposobem wyrażenia tego jest „dlaczego nie zostały złapane obiekty DB?” co jest drugą stroną medalu. Bazy danych nadal są irytującą abstrakcją, która wciąż przenika do każdej dostępnej aplikacji, ale są niezgodne z logiką OO nowoczesnych aplikacji.

To rzeczywiście dziwny stan rzeczy, że ukrywamy i powielamy funkcjonalność baz danych w ActiveRecord, Hibernate i innych programach pośrednich. Ale to właśnie dzieje się z paradygmatami w punkcie zerwania („niedopasowanie impedancji obiektowo-relacyjnej”). Czy kiedykolwiek przejdziemy na technologie bazodanowe, które są podobne do naszych aplikacji OO (np. Obiektowe bazy danych)?

Odpowiedź brzmi „nie przez długi czas”, a tymczasem spodziewaj się, że baza danych zostanie w wielu przypadkach zignorowana, zgnieciona i wykorzystana tylko do przechowywania wierszy, ponieważ funkcjonalność warstwy środkowej rośnie, aby wypełnić lukę.

Kolejne pytanie brzmi: „dlaczego miałbym to robić w bazie danych, skoro średni poziom może to zrobić?” Środkowy poziom jest znajomy i cały czas zyskuje na szybkości i funkcjonalności. Ponownie używamy warstwy środkowej, aby uniknąć niezgodności OO-RDMS.

Aby rozwinąć to, co powiedział Christian , o skalowalności.

Po prostu RDBM są używane częściej jako czyste magazyny danych, podczas gdy logika została przeniesiona do serwerów aplikacji. Dodatkowa warstwa AS zapewnia programistom większą elastyczność niż używanie RDBMS jako serwera aplikacji.

Wcześniej, w klasycznych czasach Fat Apps i Client Server, DB i Application Server były w zasadzie tym samym. Miałeś logikę aplikacji osadzoną w kodzie grubego klienta lub wepchnąłeś ją z powrotem do RDBMS. Ale wtedy podstawową formą komunikacji był SQL bezpośrednio do bazy danych.

W dzisiejszych czasach inne protokoły aplikacji są bardziej powszechne (CORBA, DCOM, Remote EJB i coraz bardziej powszechne protokoły w stylu XML / JSON / HTTP-RPC przez HTTP). Większość baz danych nie odpowiada bezpośrednio na te protokoły, więc warstwa aplikacji jest przerywana w celu przechwycenia tych wywołań, a ta warstwa wywołuje bazę danych.

Ale jak się nauczyliśmy, mamy teraz dużo większą elastyczność, wprowadzając logikę do tej warstwy. Szerszy wybór narzędzi, większa elastyczność w porównaniu z buforowaniem lub przełączaniem awaryjnym, a nawet technologia baz danych (RDMBS, OODBMS, magazyny dokumentów, takie jak CouchDB). Ten „nowy”, trzeci poziom, pomimo dodatkowej złożoności, dodaje więcej elastyczności i mocy niż złożoność, którą wprowadza.

Gdy warstwa aplikacji to bardzo cienka okleina oprócz procedur składowanych, warto zastanowić się, dlaczego w ogóle tam jest.

Wykorzystanie bazy danych i wszystkich jej funkcji jest ważną strategią aplikacji, nawet dzisiaj. SQL Server, Oracle itd. To bardzo potężne oprogramowanie.

Jednak nawet wtedy trzecia warstwa jest niezwykle pomocna w zwiększaniu elastyczności nowoczesnego systemu.

Dla mnie powodem jest nie tylko to, że moje aplikacje są agnostykami bazy danych, ale baza danych najlepiej spełnia podstawowe funkcje CRUD. Tak, bazy danych są wysoce zoptymalizowane i mogą być w stanie wykonać wywołanie HTTP, ale dlaczego miałbyś to zrobić? Usługa sieciowa / aplikacja internetowa jest zoptymalizowana pod kątem wywołań HTTP, a nie bazy danych. Podobnie jak aplikacja nie jest zaprojektowana do bezpośredniego łączenia się z plikiem danych i pobierania danych. Czy da się to zrobić? Tak ale dlaczego? Nie w tym Twoja aplikacja DOSKONAŁA.

Osobiście uważam, że wszystko, o czym wspomniałeś, poza procedurami składowanymi, należy do aplikacji. Jeśli wiesz, że twoją architekturą jest X, skorzystaj z funkcji X, ręcznie załaduj do serwera DB, gdy jest to konieczne, itp ... Jeśli może to być X lub Y (lub Z), to twoja aplikacja powinna być agnostyczna, chyba że jesteś próbując stworzyć bezpieczeństwo pracy, upewniając się, że być może będziesz musiał refaktoryzować aplikację :). Myślę, że trochę lenistwa w połączeniu z wygodą może mieć z tym coś wspólnego. Wiem, że wolałbym to zrobić w C # niż SQL, jeśli mogę. . . moje umiejętności C # są po prostu lepsze.

Po pierwsze: każdy programista używający ORM jest naiwny, jeśli uważa, że ​​używanie ORM jest negacją konieczności posiadania umiejętności SQL. Większość ORMów, które generują SQL, różni emitowany kod SQL w zależności od tego, jak skonstruowane są zapytania obiektowe. Deweloper będzie musiał przeanalizować SQL, aby sprawdzić, czy powinien zmienić którekolwiek z zapytań dotyczących obiektów.

Krótka odpowiedź: wiele z tych funkcji nie jest praktycznych dla programowania obiektowego. Wiem, że administratorzy baz danych nie lubią tego słuchać, ale taka jest prawda. Te funkcje są dobre dla skrajnych przypadków, a większość dobrych ORMów, takich jak N / Hibernate, pozwala na udostępnienie SQL dla tych skrajnych przypadków.

Jeśli chodzi o delegowanie w większości do CRUD:

Długa odpowiedź: myślę, że świat RDBMS przeżywa bóle związane z dojrzewaniem i znajduje swoje miejsce na świecie. Prawda: OOP jest starszy niż RDBMS. OOP po prostu wydostaje się z rosnących bólów i dojrzewa. Myślę, że SQL jako język jest bardzo dojrzały, ale idea tego, co RDBMS powinien obsługiwać, jest dopiero ustalana. RDBMS był operatorem logiki biznesowej dla większości aplikacji internetowych, dopóki nie pojawiły się Java i C #. Myślę, że dopiero teraz zaczynamy odczuwać tę korektę.

Biorąc to pod uwagę, nie sądzę, aby jakikolwiek projektant ORM powiedział ci, że jakość instrukcji sql podawanych do RDBMS nie ma znaczenia.

Jeśli chodzi o non-CRUD, nie mam tutaj odpowiedzi. Większość sklepów, o których wiem, nadal używa DB dla ETL / etc ...

Nie ma wystarczającej liczby programistów, którzy znają wszystkie te funkcje na poziomie, który naprawdę zrobiłby różnicę dla zwykłego programisty „średniej warstwy”, jeśli chodzi o implementację tej samej logiki w DB lub środkowej warstwie. Być może samotni ludzie, którzy naprawdę mają dogłębną wiedzę na temat tych funkcji, to administratorzy baz danych. A te koncentrują się na innych problemach niż rozwój. Jest więcej „normalnych” programistów niż administratorów baz danych. Dlatego znalezienie odpowiednich ludzi do swojego zespołu byłoby bardzo trudne i kosztowne.

Inną kwestią jest to, że zwykle gromadzisz dogłębną wiedzę tylko o jednym systemie baz danych, a nie o wszystkich. Możesz więc mieć ekspertów SQL Server lub Oracle, ale nie obu. Prowadzi to (do pewnego stopnia) do wąskich obszarów zastosowań, w których liczy się wysoka specjalizacja. Wtedy rynek takich aplikacji nie jest duży, nawet jeśli istnieje.

Myślę, że powodem jest połączenie przywiązania do dostawcy i braku wiedzy większości użytkowników RDBM. SQL jest językiem programowania i znacznie trudniej jest opanować zarówno język, z którego wywołujesz SQL, jak i SQL, niż opanować jeden lub drugi, zwłaszcza, że ​​SQL jest szczególnie unikalnym językiem.

Myślę, że rozwiązaniem jest wyodrębnienie funkcjonalności bazy danych do klasy narzędziowej i przekazanie własności tej klasy kilku użytkownikom, którzy wiedzą, co robią z SQL. Minimalizuje to ryzyko zablokowania dostawcy (jeśli zmienisz sprzedawcę, jedyną rzeczą, która zostanie przepisana, jest klasa). Daje to również programistom, którzy nie są ekspertami w SQL, wyabstrahowany interfejs, dzięki czemu nie muszą zajmować się bezpośrednio bazą danych.

Jednym z problemów, które widziałem przy wykorzystaniu zwiększonej funkcjonalności bazy danych, jest skalowanie. Wydaje się, że znacznie trudniejszą propozycją jest skalowanie obciążenia bazy danych względem obciążenia serwera WWW / aplikacji.

Twoje opcje są ograniczone, skalowalne w górę z większym, szybszym sprzętem (czasami z dużo wyższymi kosztami licencjonowania) lub skomplikowane, skalowalne w przypadku kopii tylko do odczytu itp.

Jeśli występują problemy z wydajnością, chcę, aby występowały na poziomie aplikacji serwera WWW. Przynajmniej jedną z moich opcji jest dodanie kolejnego serwera WWW i rozłożenie obciążenia.

Nie sprzeciwiam się kodowi poziomu bazy danych w celu zminimalizowania ilości ruchu sieciowego (rekordów) przesyłanych między serwerem WWW a serwerem bazy danych. Spieram się z innymi funkcjami, np. rozbudowane przetwarzanie logiki biznesowej na poziomie bazy danych.

W kilku postach zauważono, że skalowanie w warstwie aplikacji jest tańsze niż w warstwie db.

Inną kwestią są aplikacje złożone, które mają dostęp do wielu magazynów danych. Znacznie łatwiej jest pisać i utrzymywać niezależny od platformy język zapytań w warstwie aplikacji niż oddzielne zapytania specyficzne dla platformy w warstwie db.

Ponieważ pisanie oprogramowania zorientowanego obiektowo w języku hosta, z natywnymi obiektami języka hosta, bije na głowę pisanie oprogramowania proceduralnego.

Zawsze pracowałem na systemach, które są sprzedawane wielu klientom i działają na sprzęcie klienta. To prowadzi do:

• Nie wiesz, jaką wersję oprogramowania bazy danych będzie uruchamiał klient.
• Klienci mogą nie chcieć aktualizować oprogramowania bazy danych w dowolnym momencie ze względu na koszty licencji lub politykę informatyczną.
• Nawet podstawowe funkcje, takie jak zmaterializowane widoki, są dostępne tylko w niektórych „wydaniach” oprogramowania bazodanowego, mniejsi klienci często nie chcą płacić za wysokiej klasy edycję bazy danych.
• Wcześniej czy później jeden z handlowców zgodzi się na używanie oprogramowania z systemem RDBMS innego dostawcy.
• Wybór pomiędzy zapisaniem logiki raz w środkowej warstwie lub przynajmniej PL-SQL i TSQL w bazie danych to łatwy wybór!
• Wszelkie zmiany w bazie danych (nowe procedury składowane, zaktualizowane widoki itp.) Będą wymagały uprawnień administratora bazy danych; w niektórych witrynach klientów może to być znacznie trudniejsze niż po prostu zaktualizowanie oprogramowania.
• Napisanie skryptu aktualizującego bazę danych jest zawsze trudniejsze niż zainstalowanie nowej wersji bibliotek dll aplikacji. (Większość systemów kompilacji obecnie wyświetla pliki MSI jako część każdej kompilacji)
• Trudniej jest przeprowadzić testy jednostkowe w bazie danych niż w warstwie środkowej.
• Trudniej jest debugować zapisane procesy niż C #.
• Tylko dlatego, że działa w Twojej bazie danych, nie oznacza, że ​​będzie działać w bazie danych klienta, RDBMS ma zbyt wiele przełączników, które zmieniają sposób ich działania - klienci zawsze mają tendencję do ustawiania ich na różne sposoby.

Zatem biorąc pod uwagę wszystkie powyższe, korzyści z korzystania z funkcji bazy danych muszą być duże, zanim będą warte długotrwałego bólu.