Twój przykładowy kod jest tak prosty, że nie będzie dużej różnicy, ale w takim przypadku wersja statyczna najprawdopodobniej wykonałaby się lepiej.
Głównym powodem używania dynamicznego SQL w celu zwiększenia wydajności jest sytuacja, w której instrukcja SQL może się znacznie różnić — np. możesz mieć możliwość dodania dodatkowego kodu do klauzuli WHERE w czasie wykonywania w oparciu o stan systemu (ograniczenie przez podzapytanie na adresie, jeśli wprowadzono adres itp.).
Innym powodem jest to, że czasami używanie zmiennych Bind jako parametrów może przynieść efekt przeciwny do zamierzonego.
Przykładem jest sytuacja, w której masz coś w rodzaju pola statusu, w którym dane nie są równomiernie rozłożone (ale są indeksowane).
Rozważ następujące 3 stwierdzenia, gdy 95% danych jest „przetwarzanych”
SELECT col FROM table
WHERE status = 'U'-- unprocessed
AND company = :company
SELECT col FROM table
WHERE status = 'P' -- processed
AND company = :company
SELECT col FROM table
WHERE status = :status
AND company = :company
W ostatecznej wersji Oracle wybierze ogólny plan wyjaśnień. W pierwszej wersji może zdecydować, że najlepszym planem jest rozpoczęcie od indeksowania statusu (wiedząc, że „Nieprzetworzone wpisy stanowią bardzo małą część całości).
Możesz to zaimplementować za pomocą różnych instrukcji statycznych, ale tam, gdzie masz bardziej złożone instrukcje, które zmieniają się tylko o kilka znaków, dynamiczny SQL może być lepszą opcją.
Wady
Każde powtórzenie tej samej dynamicznej instrukcji SQL wiąże się z miękką analizą, która jest niewielkim obciążeniem w porównaniu do instrukcji statycznej, ale nadal jest obciążeniem.
Każda instrukcja NEW sql (dynamiczna lub statyczna) również blokuje SGA (pamięć współdzieloną) i może skutkować wypchnięciem „starych” instrukcji.
Zły, ale powszechny projekt systemu polega na tym, że ktoś używa dynamicznego SQL do generowania prostych wyborów, które różnią się tylko kluczem - tj.
SELECT col FROM table WHERE id = 5
SELECT col FROM table WHERE id = 20
SELECT col FROM table WHERE id = 7
Poszczególne stwierdzenia będą szybkie, ale ogólna wydajność systemu ulegnie pogorszeniu, ponieważ zabija współdzielone zasoby.
Ponadto — znacznie trudniej jest wyłapać błędy w czasie kompilacji za pomocą dynamicznego SQL. Jeśli używasz PL/SQL, oznacza to utratę dobrej kontroli czasu kompilacji. Nawet jeśli używasz czegoś takiego jak JDBC (gdzie przenosisz cały kod bazy danych do łańcuchów - dobry pomysł!) możesz uzyskać preparsery do walidacji zawartości JDBC. Dynamiczny SQL =tylko testowanie w czasie wykonywania.
Koszty ogólne
Narzut natychmiastowego wykonania jest niewielki — mieści się w tysięcznych częściach sekundy — jednak może się sumować, jeśli odbywa się to w pętli / w metodzie wywoływanej raz na obiekt / itd. Kiedyś uzyskałem 10-krotną poprawę szybkości poprzez zastąpienie dynamic SQL z wygenerowanym statycznym SQL. Jednak to skomplikowało kod i zostało zrobione tylko dlatego, że potrzebowaliśmy szybkości.
