Porównanie SQL, konstruktorów zapytań i ORM

Wprowadzenie

Używanie bazy danych do zarządzania danymi aplikacji jest jednym z najczęstszych sposobów utrwalania danych. Bazy danych umożliwiają szybkie przechowywanie i wyszukiwanie informacji, zapewniają gwarancje integralności danych i oferują trwałość poza okres istnienia pojedynczej instancji aplikacji. Dostępne są niezliczone rodzaje baz danych, które spełniają wymagania Twojego projektu i Twoje preferencje.

Jednak praca bezpośrednio z bazami danych z Twojej aplikacji nie zawsze jest łatwa. Różnice w sposobie reprezentacji struktur danych często prowadzą do wyzwań. Trudność w wyrażaniu subtelności dotyczących relacji między różnymi podmiotami może również powodować problemy. Aby temu zaradzić, stworzono wiele różnych narzędzi, które pomagają działać jako interfejs między podstawową aplikacją a warstwą danych.

W tym przewodniku przyjrzymy się niektórym różnicom, które pojawiają się między trzema popularnymi podejściami:surowym SQL, konstruktorami zapytań i ORM (mapowanie obiektowo-relacyjne). Porównamy niektóre zalety i wady każdego podejścia, a następnie zakończymy słownikiem powszechnie używanych terminów, aby pomóc w zapoznaniu się z niektórymi kluczowymi pojęciami.

Jako uproszczone podsumowanie, oto ogólny widok mocnych i słabych stron każdego podejścia:

Zarządzanie danymi za pomocą surowego SQL lub innego języka zapytań natywnego dla bazy danych

Niektóre aplikacje łączą się bezpośrednio z bazą danych, pisząc i wykonując zapytania w natywnym języku obsługiwanym przez silnik bazy danych. Często sterownik bazy danych jest wszystkim, co jest potrzebne do połączenia, uwierzytelnienia i komunikacji z instancją bazy danych.

Deweloperzy mogą wysyłać zapytania napisane w ojczystym języku bazy danych za pośrednictwem połączenia. W zamian baza dostarczy wyniki zapytania, również w jednym ze swoich natywnych formatów. W przypadku wielu relacyjnych baz danych preferowanym językiem zapytań jest SQL.

Większość relacyjnych baz danych, a także niektóre nierelacyjne bazy danych, obsługuje ustrukturyzowany język zapytań, znany również jako SQL, do tworzenia i wykonywania potężnych zapytań. SQL jest używany do zarządzania danymi od lat 70., więc jest dobrze obsługiwany i do pewnego stopnia ustandaryzowany.

Korzyści z zapytań natywnych

Korzystanie z SQL lub innego języka natywnego dla bazy danych ma kilka wyraźnych korzyści.

Jedną z zalet jest to, że programiści piszą zapytania do bazy danych i zarządzają nimi oraz jawnie przetwarzają wyniki. Chociaż może to wymagać dużo dodatkowej pracy, oznacza to, że istnieje niewiele niespodzianek, jeśli chodzi o to, co przechowuje baza danych, jak reprezentuje dane i jak dostarczy te dane, gdy zostaną później pobrane. Brak abstrakcji oznacza, że ​​jest mniej „ruchomych części”, które mogą prowadzić do niepewności.

Jednym z przykładów jest wydajność. Podczas gdy zaawansowane warstwy abstrakcji generują zapytania SQL poprzez tłumaczenie instrukcji programowania, wygenerowany kod SQL może być bardzo nieefektywny. Niepotrzebne klauzule, zbyt szerokie zapytania i inne wpadki mogą prowadzić do powolnych operacji bazy danych, które mogą być delikatne i trudne do debugowania. Pisząc natywnie w SQL, możesz wykorzystać całą swoją wiedzę o domenie i zdrowy rozsądek, aby uniknąć wielu klas problemów z zapytaniami

Innym powodem używania zapytań natywnych dla bazy danych jest elastyczność. Żadna abstrakcja prawdopodobnie nie będzie tak elastyczna, jak natywny język zapytań do bazy danych. Wyższe poziomy abstrakcji próbują wypełnić lukę między dwoma różnymi paradygmatami, które mogą ograniczać rodzaje operacji, które mogą wyrażać. Jednak pisząc w surowym SQL, możesz skorzystać ze wszystkich funkcji silnika bazy danych i wyrazić bardziej złożone zapytania.

Wady zapytań natywnych

Chociaż natywne zapytania mają pewne mocne strony, nie są pozbawione problemów.

Podczas interakcji z bazą danych z poziomu aplikacji używającej zwykłego języka SQL należy zrozumieć podstawową strukturę danych, aby tworzyć prawidłowe zapytania. Ponosisz całkowitą odpowiedzialność za tłumaczenie między typami danych i strukturami używanymi przez Twoją aplikację a konstrukcjami dostępnymi w systemie bazy danych.

Inną rzeczą, o której należy pamiętać podczas pracy z surowym SQL, jest to, że zarządzanie bezpieczeństwem danych wejściowych zależy wyłącznie od Ciebie. Jest to szczególnie ważne, jeśli przechowujesz dane dostarczone przez użytkowników zewnętrznych, gdzie specjalnie spreparowane dane wejściowe mogą spowodować, że Twoja baza danych ujawni informacje, których nie zamierzałeś zezwolić.

Ten rodzaj exploita nazywa się wstrzyknięciem SQL i stanowi potencjalny problem, gdy dane wprowadzone przez użytkownika mogą wpłynąć na stan bazy danych. Narzędzia wyższej abstrakcji często automatycznie oczyszczają dane wejściowe użytkownika, pomagając uniknąć tej klasy problemów.

Praca z natywnymi językami zapytań prawie zawsze oznacza tworzenie zapytań ze zwykłymi ciągami. Może to być bolesny proces w przypadkach, gdy musisz zmienić dane wejściowe i połączyć ze sobą ciągi, aby utworzyć prawidłowe zapytanie. Operacje na Twojej bazie danych mogą zostać owinięte w wiele warstw manipulacji ciągami, które mają duży potencjał do przypadkowego zniekształcenia danych.

Podsumowanie zapytań natywnych

Chociaż w tej sekcji mówiliśmy przede wszystkim o SQL, większość zawartych tutaj informacji odnosi się równie dobrze do dowolnego natywnego języka zapytań do bazy danych. Podsumowując, surowy SQL lub bezpośrednie użycie dowolnego równoważnego języka zapytań przybliża Cię do abstrakcji używanych przez bazę danych do przechowywania danych i zarządzania nimi, ale zmusza Cię do wykonania wszystkich trudów związanych z ręcznym zarządzaniem danymi.

Zarządzanie danymi za pomocą konstruktorów zapytań

Alternatywnym podejściem do używania języków zapytań natywnych dla bazy danych, takich jak SQL, jest użycie narzędzia lub biblioteki zwanej konstruktorem zapytań do komunikacji z bazą danych.

Czym są kreatory zapytań SQL?

Konstruktor zapytań SQL dodaje warstwę abstrakcji ponad nieprzetworzone języki zapytań natywne dla bazy danych. Robią to, formalizując wzorce zapytań i dostarczając metody lub funkcje, które dodają sanitację danych wejściowych i automatycznie zmieniają pozycje w celu łatwiejszej integracji z aplikacjami.

Struktury i akcje obsługiwane przez warstwę bazy danych są nadal dość rozpoznawalne podczas korzystania z konstruktorów zapytań SQL. Pozwala to na programową pracę z danymi, pozostając stosunkowo blisko danych.

Zwykle konstruktory zapytań udostępniają interfejs, który używa metod lub funkcji w celu dodania warunku do zapytania. Łącząc metody, programiści mogą tworzyć kompletne zapytania do bazy danych na podstawie tych indywidualnych „klauzul”.

Korzyści z konstruktorów zapytań SQL

Ponieważ konstruktorzy zapytań używają tych samych konstrukcji (metod lub funkcji) co reszta aplikacji, programiści często uważają je za łatwiejsze w zarządzaniu w dłuższej perspektywie niż nieprzetworzone zapytania do bazy danych zapisane jako ciągi. Łatwo jest odróżnić operatory od danych i łatwo jest rozłożyć zapytania na logiczne porcje, które obsługują określone części zapytania.

Dla niektórych programistów kolejną zaletą korzystania z konstruktora zapytań SQL jest to, że nie zawsze ukrywa on bazowy język zapytań. Chociaż operacje mogą używać metod zamiast ciągów, może to być dość przejrzyste, co ułatwia osobom zaznajomionym z bazą danych zrozumienie, co zrobi operacja. Nie zawsze tak jest w przypadku korzystania z wyższych poziomów abstrakcji.

Konstruktorzy zapytań SQL często obsługują również wiele zapleczy danych, abstrahując na przykład niektóre z subtelnych różnic w różnych relacyjnych bazach danych. Pozwala to na używanie tych samych narzędzi do projektów korzystających z różnych baz danych. Może nawet nieco ułatwić migrację do nowej bazy danych.

Wady konstruktorów zapytań SQL

Konstruktorzy zapytań SQL mają kilka takich samych wad, jak natywne języki zapytań.

Popularną krytyką jest to, że kreatory zapytań SQL nadal wymagają zrozumienia i uwzględnienia struktur i możliwości bazy danych. Dla niektórych programistów nie jest to wystarczająco użyteczna abstrakcja. Oznacza to, że oprócz specyficznej składni i możliwości samego konstruktora zapytań musisz dość dobrze znać SQL.

Ponadto konstruktory zapytań SQL nadal wymagają zdefiniowania, w jaki sposób pobierane dane mają związek z danymi aplikacji. Nie ma automatycznej synchronizacji między obiektami w pamięci a obiektami w bazie danych.

Podczas gdy kreatory zapytań często emulują język zapytań, z którym mają pracować, dodatkowa warstwa abstrakcji może oznaczać, że czasami niektóre operacje nie są możliwe przy użyciu dostarczonych metod. Zwykle istnieje „surowy” tryb wysyłania zapytań bezpośrednio do zaplecza, z pominięciem typowego interfejsu konstruktora zapytań, ale to omija problem, zamiast go rozwiązywać.

Podsumowanie konstruktorów zapytań SQL

Ogólnie rzecz biorąc, konstruktory zapytań SQL oferują cienką warstwę abstrakcji, która koncentruje się w szczególności na niektórych głównych problemach związanych z bezpośrednią pracą z językami natywnymi dla bazy danych. Konstruktorzy zapytań SQL działają prawie jak system szablonów do zapytań, pozwalając programistom przejść linię między bezpośrednią pracą z bazą danych a dodawaniem dodatkowych warstw abstrakcji.

Zarządzanie danymi za pomocą ORM

Krok dalej w hierarchii abstrakcji znajdują się ORM-y. ORM generalnie mają na celu pełniejszą abstrakcję z nadzieją na płynniejszą integrację z danymi aplikacji.

Co to są ORM-y?

Mapery obiektowo-relacyjne lub ORM to części oprogramowania przeznaczone do tłumaczenia między reprezentacjami danych w relacyjnych bazach danych a reprezentacją w pamięci stosowaną w programowaniu obiektowym (OOP). ORM zapewnia zorientowany obiektowo interfejs do danych w bazie danych, próbując wykorzystać znane koncepcje programowania i zmniejszyć ilość kodu szablonowego niezbędnego w celu przyspieszenia rozwoju.

Ogólnie rzecz biorąc, ORM służą jako warstwa abstrakcji, która ma pomóc programistom w pracy z bazami danych bez drastycznej zmiany paradygmatu obiektowego. Może to być pomocne, zmniejszając obciążenie umysłowe dostosowywaniem się do specyfiki formatu przechowywania bazy danych.

W szczególności obiekty w programowaniu obiektowym mają tendencję do kodowania w sobie wielu stanów i mogą mieć złożone relacje z innymi obiektami poprzez dziedziczenie i inne koncepcje OOP. Wiarygodne odwzorowanie tych informacji w paradygmacie relacyjnym zorientowanym na tabelę często nie jest proste i może wymagać dobrego zrozumienia obu systemów. ORM próbują zmniejszyć to obciążenie, automatyzując niektóre z tych mapowań i zapewniając ekspresyjne interfejsy do danych w systemie.

Czy wyzwania związane z ORM-ami są specyficzne dla programowania obiektowego i relacyjne bazy danych?

Z definicji ORM są specjalnie zaprojektowane do łączenia się między obiektowymi językami aplikacji a relacyjnymi bazami danych. Jednak próba mapowania i tłumaczenia między abstrakcjami struktury danych używanymi w językach programowania a tymi używanymi przez magazyny baz danych jest bardziej ogólnym problemem, który może wystąpić, gdy abstrakcje nie są dokładnie wyrównane.

W zależności od paradygmatu programowania (obiektowego, funkcjonalnego, proceduralnego itp.) oraz typu bazy danych (relacyjna, dokumentowa, klucz-wartość itp.) pomocne mogą być różne poziomy abstrakcji. Często złożoność struktur danych w aplikacji decyduje o tym, jak łatwo jest komunikować się z magazynem danych.

Programowanie obiektowe ma tendencję do tworzenia wielu struktur ze znaczącym stanem i relacjami, które należy uwzględnić. Niektóre inne paradygmaty programowania są bardziej jednoznaczne w kwestii tego, gdzie stan jest przechowywany i jak jest zarządzany. Na przykład, czysto funkcjonalne języki nie pozwalają na zmienny stan, więc stan jest często wejściem dla funkcji lub obiektów, które wyprowadzają nowy stan. To czyste oddzielenie danych od działań, a także jednoznaczność cykli życia stanu może pomóc uprościć interakcję z bazą danych.

Tak czy inaczej, często dostępna jest opcja łączenia się z bazą danych za pomocą oprogramowania, które odwzorowuje dwie różne reprezentacje. Tak więc, podczas gdy ORM opisują określony podzbiór z unikalnymi wyzwaniami, mapowanie między pamięcią aplikacji a pamięcią stałą często wymaga rozważenia niezależnie od szczegółów.

Rekord aktywny a ORM-y mapowania danych

Różne systemy ORM stosują różne strategie mapowania struktur aplikacji i baz danych. Dwie główne kategorie to aktywny wzorzec rekordów i wzorzec mapowania danych .

Wzorzec aktywnego rekordu próbuje hermetyzować dane bazy danych w strukturze obiektów w kodzie. Obiekty zawierają metody zapisywania, aktualizowania lub usuwania z bazy danych, a zmiany w obiektach mają być łatwo odzwierciedlone w bazie danych. Ogólnie rzecz biorąc, obiekt aktywnego rekordu w Twojej aplikacji reprezentuje rekord w bazie danych.

Implementacje Active Record umożliwiają zarządzanie bazą danych poprzez tworzenie i łączenie klas i instancji w kodzie. Ponieważ zazwyczaj mapują one instancje klas bezpośrednio na rekordy bazy danych, łatwo jest określić, co znajduje się w Twojej bazie danych, jeśli rozumiesz, jakie obiekty są używane w Twoim kodzie.

Niestety, może to mieć również poważne wady. Aplikacje są zwykle bardzo ściśle powiązane z bazą danych, co może powodować problemy podczas próby migracji do nowej bazy danych lub nawet podczas testowania kodu. Twój kod ma tendencję do polegania na bazie danych, aby wypełnić luki, które zostały usunięte z twoich obiektów. „Magiczne” tłumaczenie między tymi dwiema domenami może również prowadzić do problemów z wydajnością, ponieważ system próbuje bezproblemowo mapować złożone obiekty do podstawowej struktury danych.

Wzorzec mapowania danych jest innym powszechnym wzorcem ORM. Podobnie jak wzorzec aktywnego rekordu, mapowanie danych próbuje działać jako niezależna warstwa między kodem a bazą danych, która pośredniczy między nimi. Jednak zamiast próbować bezproblemowo integrować obiekty i rekordy bazy danych, skupia się na próbach oddzielenia i tłumaczenia między nimi, jednocześnie pozwalając każdemu istnieć niezależnie. Może to pomóc oddzielić logikę biznesową od szczegółów związanych z bazą danych, które dotyczą mapowań, reprezentacji, serializacji itp.

Dlatego zamiast pozwolić systemowi ORM dowiedzieć się, jak mapować obiekty i tabele bazy danych, programista jest odpowiedzialny za jawne mapowanie między nimi. Może to pomóc w uniknięciu ścisłego sprzężenia i operacji zakulisowych kosztem znacznie większej ilości pracy przy opracowywaniu odpowiednich mapowań.

Korzyści z ORM

ORM są popularne z wielu powodów.

Pomagają wyodrębnić podstawową domenę danych do czegoś, co jest łatwe do zrozumienia w kontekście aplikacji. Zamiast myśleć o przechowywaniu danych jako niezależnym systemie, ORM pomagają uzyskać dostęp do systemów danych i zarządzać nimi jako rozszerzenie bieżącej pracy. Może to pomóc programistom w szybszej pracy nad podstawową logiką biznesową, zamiast grzęznąć w niuansach zaplecza pamięci masowej.

Innym skutkiem ubocznym jest to, że ORM-y usuwają wiele szablonów niezbędnych do łączenia się z bazami danych. ORM często zawierają narzędzia do migracji, które pomagają zarządzać zmianami w schemacie bazy danych na podstawie zmian wprowadzonych w kodzie. Nie musisz koniecznie od razu wymyślać idealnego schematu bazy danych, jeśli Twój ORM może pomóc w zarządzaniu zmianami w strukturze bazy danych. Zmiany w aplikacji i bazie danych często są takie same lub są ściśle powiązane, co pomaga śledzić zmiany w bazie danych podczas wprowadzania zmian w kodzie.

Wady ORM

ORM-y nie są pozbawione wad. W wielu przypadkach wynikają one z tych samych decyzji, które sprawiają, że ORM są przydatne.

Jednym z podstawowych problemów z ORM-ami jest próba ukrycia szczegółów backendu bazy danych. Takie zaciemnianie sprawia, że ​​praca z ORM-ami jest łatwiejsza w prostych przypadkach lub w małej skali czasowej, ale często prowadzi do problemów w miarę wzrostu złożoności.

Abstrakcja nigdy nie jest w 100% kompletna, a próba użycia ORM bez zrozumienia bazowego języka zapytań lub struktury bazy danych często prowadzi do problematycznych założeń. Może to utrudnić lub uniemożliwić debugowanie i dostrajanie wydajności.

Być może najbardziej znanym problemem związanym z pracą z ORM-ami jest obiektowo-relacyjne niedopasowanie impedancji, termin używany do opisania trudności w tłumaczeniu między programowaniem obiektowym a paradygmatem relacyjnym używanym przez relacyjne bazy danych. Niezgodności między modelami danych używanymi przez te dwie kategorie technologii oznaczają, że przy każdym wzroście złożoności konieczna jest dodatkowa, niedoskonała abstrakcja. Obiektowo-relacyjne niedopasowanie impedancji zostało nazwane Wietnamem informatyki (w odniesieniu do wojny w Wietnamie) ze względu na jej tendencję do zwiększania złożoności w czasie i prowadzi do sytuacji, w których ścieżki do sukcesu lub zmiany kursu są trudne lub niemożliwe.

Ogólnie rzecz biorąc, ORM wydają się być wolniejsze niż alternatywy, zwłaszcza w przypadku złożonych zapytań. ORM często generują skomplikowane zapytania dla stosunkowo prostych operacji na bazie danych, ponieważ stosują ogólne wzorce, które muszą być wystarczająco elastyczne, aby obsłużyć inne przypadki. Poleganie na ORM, aby postępować właściwie w każdych okolicznościach, może prowadzić do kosztownych błędów, które mogą być trudne do nadrobienia z góry.

Podsumowanie ORM

ORM mogą być użytecznymi abstrakcjami, które znacznie ułatwiają pracę z bazami danych. Mogą pomóc w szybkim projektowaniu i iteracji oraz zniwelować różnice koncepcyjne między logiką aplikacji a strukturami bazy danych. Jednak wiele z tych zalet działa jak miecz obosieczny. Mogą uniemożliwić Ci zrozumienie Twoich baz danych i mogą utrudnić debugowanie, zmianę paradygmatów lub zwiększenie wydajności.

Słownik

Podczas pracy z technologiami, które łączą bazy danych i aplikacje, możesz napotkać terminologię, której nie znasz. W tej sekcji pokrótce omówimy niektóre z najczęstszych terminów, z którymi możesz się spotkać, niektóre z nich zostały omówione wcześniej w tym artykule, a niektóre nie.

• Mapowanie danych: Maper danych to wzorzec projektowy lub oprogramowanie, które odwzorowuje struktury danych programowych na te przechowywane w bazie danych. Programy mapujące dane próbują zsynchronizować zmiany między dwoma źródłami, zachowując je jednocześnie niezależnie od siebie. Sam program odwzorowujący jest odpowiedzialny za utrzymanie działającego tłumaczenia, uwalniając programistów od iteracji struktur danych aplikacji bez obaw o reprezentację bazy danych.
• Sterownik bazy danych: Sterownik bazy danych to oprogramowanie zaprojektowane do enkapsulacji i umożliwienia połączeń między aplikacją a bazą danych. Sterowniki baz danych abstrahują szczegóły niskiego poziomu dotyczące tworzenia połączeń i zarządzania nimi oraz zapewniają ujednolicony, programowy interfejs do systemu bazy danych. Zazwyczaj sterowniki baz danych są najniższym poziomem abstrakcji, którego programiści używają do interakcji z bazami danych, przy czym narzędzia wyższego poziomu opierają się na możliwościach zapewnianych przez sterownik.
• Atak iniekcji: Atak polegający na wstrzyknięciu to atak, w którym złośliwy użytkownik próbuje wykonać niepożądane operacje na bazie danych przy użyciu specjalnie spreparowanych danych wejściowych w polach aplikacji dostępnych dla użytkownika. Często jest to używane do pobierania danych, które nie powinny być dostępne, lub do usuwania lub zniekształcania informacji w bazie danych.
• ORM: ORM lub mapery obiektowo-relacyjne to warstwy abstrakcji, które tłumaczą między reprezentacjami danych używanymi w relacyjnych bazach danych a reprezentacją w pamięci używaną z programowaniem obiektowym. ORM zapewnia zorientowany obiektowo interfejs do danych w bazie danych, próbując zmniejszyć ilość kodu i użyć znanych archetypów w celu przyspieszenia rozwoju.
• Niedopasowanie impedancji obiektowo-relacyjnej: Niedopasowanie impedancji obiektowo-relacyjnej odnosi się do trudności w tłumaczeniu między aplikacją zorientowaną obiektowo a relacyjną bazą danych. Ponieważ struktury danych znacznie się różnią, wierne i wydajne mutowanie i transkrypcja programistycznych struktur danych do formatu używanego przez zaplecze pamięci może być trudne.
• Struktura trwałości: Struktura trwałości to warstwa abstrakcji oprogramowania pośredniego opracowana w celu wypełnienia luki między danymi programu a bazami danych. Struktury trwałe mogą być również ORM-ami, jeśli abstrakcja, której używają, odwzorowuje obiekty na encje relacyjne.
• Konstruktor zapytań: Konstruktor zapytań to warstwa abstrakcji, która pomaga programistom uzyskać dostęp do baz danych i kontrolować je, zapewniając kontrolowany interfejs, który dodaje funkcje użyteczności, bezpieczeństwa lub elastyczności. Zazwyczaj konstruktory zapytań są stosunkowo lekkie, koncentrują się na ułatwieniu dostępu do danych i reprezentacji danych oraz nie próbują tłumaczyć danych na określony paradygmat programowania.
• SQL: SQL lub ustrukturyzowany język zapytań to język specyficzny dla domeny, opracowany do zarządzania systemami zarządzania relacyjnymi bazami danych. Może być używany do odpytywania, definiowania i manipulowania danymi w bazie danych, jak również w ich strukturach organizacyjnych. SQL jest wszechobecny wśród relacyjnych baz danych.

Wniosek

W tym artykule przyjrzeliśmy się kilku różnym opcjom łączenia się z bazą danych z poziomu Twojej aplikacji. Zbadaliśmy różne poziomy abstrakcji i elastyczność oferowaną przez używanie natywnych dla bazy danych języków zapytań, takich jak SQL, używanie konstruktora zapytań do bezpiecznego tworzenia zapytań oraz ORM, aby zapewnić pełniejszy poziom abstrakcji.

Każde z tych podejść ma swoje zastosowania, a niektóre mogą być dobrze dopasowane do pewnych typów zastosowań niż inne. Ważne jest, aby zrozumieć wymagania aplikacji, wiedzę o bazie danych organizacji oraz koszty abstrakcji (lub ich braku), które zdecydujesz się wdrożyć. Ogólnie rzecz biorąc, zrozumienie każdego podejścia da Ci największą szansę na wybranie opcji, która będzie dobrze pasować do Twoich projektów.