Statyczne vs dynamiczne SQL

Statyczne SQL ma z góry określoną treść zapytania, dynamiczne buduje ją w trakcie wykonania jako tekst.

Na czym polega różnica między statycznym a dynamicznym SQL

Statyczne SQL oznacza zapytanie, którego struktura jest ustalona przed wykonaniem programu. W kodzie aplikacji albo w procedurze zapisane są konkretne polecenia, takie jak SELECT, INSERT, UPDATE lub DELETE, a ich składnia nie jest tworzona na podstawie tekstu złożonego w czasie działania. Wartości zmienne, na przykład identyfikator użytkownika albo zakres dat, mogą być przekazywane jako parametry. Nie zmienia to statycznego charakteru zapytania, ponieważ zmieniają się dane wejściowe, a nie jego struktura.

Dynamiczne SQL powstaje podczas działania programu. Aplikacja, procedura lub skrypt buduje tekst zapytania, a następnie przekazuje go do mechanizmu bazy danych w celu analizy i wykonania. Tekst może zależeć od wybranych kolumn, tabel, warunków filtrowania, sortowania albo innych elementów składni. W praktyce granica między tymi pojęciami zależy od używanego narzędzia: niektóre systemy przygotowują statyczne zapytania wcześniej, inne analizują je dopiero przy wywołaniu. Istotą porównania jest jednak to, czy program zmienia samą strukturę polecenia, czy tylko wartości przekazywane do ustalonego zapytania.

Wykonanie zapytania, analiza składni i plan działania

Przed wykonaniem zapytania silnik bazy danych musi sprawdzić jego składnię, rozpoznać odwołania do tabel i kolumn oraz wybrać sposób dostępu do danych. Ten sposób jest nazywany planem wykonania. Przy statycznym SQL struktura zapytania jest znana wcześniej, dlatego aplikacja może korzystać z zapytań przygotowanych lub z kodu, który został skompilowany razem z procedurą. Wartości parametrów są wtedy przekazywane oddzielnie od tekstu polecenia. Ułatwia to rozróżnienie danych od instrukcji i może ograniczyć koszt wielokrotnego analizowania tego samego zapytania.

W dynamicznym SQL zmiana tekstu zapytania może spowodować ponowną analizę składni i wybór innego planu wykonania. Nie zawsze jest to wada. Jeżeli program rzeczywiście musi wybierać różne tabele, kolumny lub warunki, odrębny tekst może pozwolić silnikowi lepiej dopasować plan do konkretnego przypadku. Z drugiej strony tworzenie wielu podobnych tekstów, różniących się tylko wartościami, może utrudnić ponowne wykorzystanie planów i zwiększyć obciążenie związane z analizą zapytań. Szczegółowe zachowanie zależy od konkretnego silnika bazy danych, jego ustawień oraz sposobu wywołania polecenia.

Parametry, wstrzykiwanie SQL i bezpieczne składanie poleceń

Najczęstszy błąd przy dynamicznym SQL polega na bezpośrednim dołączaniu danych użytkownika do tekstu zapytania. Jeżeli aplikacja łączy napis zawierający warunek z wartością pochodzącą z formularza, adresu internetowego lub pliku, specjalnie przygotowany tekst może zostać potraktowany jako część instrukcji SQL. Taki atak nazywa się wstrzykiwaniem SQL. Może prowadzić do odczytu, zmiany albo usunięcia danych, zależnie od uprawnień konta używanego przez aplikację.

Podstawową metodą ograniczenia tego ryzyka jest używanie parametrów zapytań przygotowanych. W takim rozwiązaniu tekst instrukcji jest przekazywany osobno, a wartości osobno, więc zawartość parametru pozostaje daną, nawet jeśli zawiera znaki mające znaczenie w składni SQL. Samo zastępowanie znaków apostrofami albo ręczne „oczyszczanie” napisu nie jest równoważne parametryzacji i łatwo może zostać wykonane niepełnie. Parametry zwykle służą do przekazywania wartości, ale nie mogą dowolnie zastępować nazw tabel, nazw kolumn ani słów kluczowych. Gdy aplikacja musi dynamicznie wybrać taki element, powinna korzystać z zamkniętej listy dozwolonych identyfikatorów i umieszczać w zapytaniu wyłącznie wartość wybraną z tej listy.

Dobór rozwiązania podczas pracy z aplikacją i bazą danych

Statyczne SQL jest właściwym wyborem wtedy, gdy zestaw operacji i ich struktura są znane z góry. Typowym przykładem jest wyszukiwanie rekordu po identyfikatorze, zapis formularza, aktualizacja określonych pól albo pobieranie danych według kilku stałych warunków. Taki kod jest łatwiejszy do przeglądania, testowania i monitorowania. Można sprawdzić, jakie tabele są używane, jakie wartości są parametrami oraz jakie uprawnienia są potrzebne do wykonania operacji. Stała struktura ułatwia także wykrywanie błędów składni i porównywanie planów wykonania.

Dynamiczne SQL ma uzasadnienie przy generowaniu raportów z opcjonalnymi filtrami, obsłudze zmiennej liczby kolumn lub wyborze obiektu bazy danych na podstawie wcześniej zweryfikowanej konfiguracji. Powinno być wtedy budowane w jasno określonym miejscu, z rozdzieleniem elementów składni od wartości danych. Warto rejestrować typ operacji, użyte parametry w bezpiecznej postaci oraz czas wykonania, aby można było rozpoznać błędne warunki i nieefektywne zapytania. Podczas diagnostyki problemów z aplikacją sprawdza się między innymi, czy zapytanie statyczne nie otrzymuje wartości w niewłaściwym typie, czy zapytanie dynamiczne nie tworzy nieoczekiwanych wariantów tekstu oraz czy błąd powstaje w aplikacji, podczas analizy składni, czy dopiero w trakcie dostępu do danych.