Dlaczego chcesz uniknąć dynamicznego SQL w procedurze przechowywanej?


13

Słyszałem, że jeden powiedział, że nie chcesz używać dynamicznego SQL. Czy możesz podać konkretny przykład lub przykład z życia? Osobiście koduję go kilka razy w mojej bazie danych. Myślę, że jest OK, ponieważ jest elastyczny. Domyślam się, że chodzi o SQL Injection lub Performance. Coś jeszcze?

Odpowiedzi:


7

Jeśli musisz, korzystanie z dynamicznego SQL nie jest niczym złym. W rzeczywistości w niektórych okolicznościach jest to jedyna dostępna opcja. Zaleca się, aby nie używać go, ponieważ tak, może prowadzić do wstrzyknięcia SQL, jeśli dane wejściowe nie są dezynfekowane, i tak, używanie dynamicznego SQL w często wywoływanych modułach może mieć negatywny wpływ na jego wydajność.

Nie wydaje mi się, aby istniał konkretny przykład, ale powiedziałbym tak: spróbuj osiągnąć to, czym jesteś po użyciu regularnych zapytań i instrukcji - dopiero wtedy, gdy wyczerpiesz wszystkie inne możliwości, zrób to dynamicznie. Pamiętaj tylko, że wykonanie dynamicznego ciągu SQL odbywa się w oddzielnej sesji użytkownika od modułu, który go wywołuje - więc możesz napotkać problemy z uprawnieniami, których się nie spodziewasz.

Jeśli martwisz się wydajnością; Sprawdź to. Jeśli martwisz się o bezpieczeństwo; sprawdź poprawność wprowadzonych danych. Nie ma żadnego dobra ani zła - wystarczy, że wykorzystasz swój najlepszy osąd w oparciu o informacje i narzędzia, które masz do dyspozycji w tym czasie.


5

Dynamiczny SQL jest narzędziem. A jako narzędzie ma kilka aplikacji - na przykład dla prac administracyjnych jest błogosławieństwem.

Nie tak dobrze na SP używany przez aplikacje, zwłaszcza jeśli nie zarządzałeś parametryzacją generowanego kodu (najnowsze wersje SQL Server zmniejszyły problemy, ale nadal są ważne).

Nie będę tutaj szczegółowo wpisywać, dlatego polecę doskonały artykuł na temat zagadnień związanych z dynamicznym SQL: Klątwa i błogosławieństwa dynamicznego SQL autorstwa MVP Erland Sommarskog.


1
Zamierzałem również udostępnić ten link, to musi przeczytać każdy, kto rozważa użycie dynamicznego SQL.
HLGEM

1

To jest jak większość funkcji dbms, jeśli użyjesz go w odpowiedniej sytuacji, to robi to dobrze, a niewłaściwa sytuacja robi to źle.

Plusy: Niektórych rzeczy po prostu nie da się bez tego zrobić. Zazwyczaj uważam, że jest to tylko praca administracyjna, a nie kod aplikacji. Niektóre polecenia systemowe nie pozwalają na użycie parametrów jako danych wejściowych. Na przykład, jeśli muszę uruchomić coś przez sproc na każdej bazie danych, w wielu przypadkach z nieznanymi bazami danych, a polecenie nie akceptuje parametrów, zwykle rozwiązuję to za pomocą dynamicznego SQL. Jednak w Sybase ASE jest to coś więcej niż MSSQL.

Minusy: nie będę się w to zbytnio zastanawiał, ponieważ myślę, że wszyscy już to wiemy, ale może być pewne ryzyko zastrzyku SQL, jeśli zostanie użyte nieprawidłowo. Dla mnie większe jest to, że zapytanie będzie traktowane jak to, co jest, unikalne zapytanie adhoc, a nie część skompilowanego planu zapytań. Dla czegoś, co działa sporadycznie, nic wielkiego. Dla czegoś, co jest wykonywane setki razy na minutę i które będzie miało wiele unikalnych sql, wygenerowałoby wiele nowych, potencjalnie niepotrzebnych, planów kwerendy pochłaniających cykle i skracających prawidłowy czas bufora planu.


Doskonałe zastosowanie aplikacji w Sybase ASE umożliwia przestawianie bez znajomości wartości, które mają być przestawiane. Można to zrobić za pomocą dynamicznego SQL w przechowywanym proc, ale o ile wiem Sybase ASE nie obsługuje składni, aby zrobić to bezpośrednio jako zapytanie. Dopiero po poznaniu wartości można zapisać zapytanie w celu przestawienia danych.
richardcrossley

-7

Nie używaj dynamicznego SQL.

99% czasu używa się dynamicznego SQL z powodu braku wiedzy na temat używania opcjonalnych parametrów w procedurach przechowywanych, reszta 1% czasu jest wykorzystywana do tworzenia bardzo złożonego zapytania dotyczącego raportu, którego klient nie rozumie parzysty. Klątwa i błogosławieństwa dynamicznego SQL nie pokazują przykładu, dlaczego warto go używać, zamiast tego sugeruje, że jest problematyczny, ponieważ zwiększa złożoność debugowania, utrzymywania, nie mówiąc już o zagrożeniach bezpieczeństwa związanych z SQL Wtrysk, niska wydajność nie dlatego, że pamięć podręczna, ale złe praktyki, które się z nią wiążą, takie jak używanie tymczasowych tabel i kursorów, które oczywiście są leniwe i naiwneprogramista nadużywałby. Nie ma czegoś takiego jak elastyczność w pisaniu zapytań w ten sposób, SQL jest językiem deklaratywnym i powinien być traktowany jako taki.

Lenistwo jest źródłem wszelkiego zła.

Paradoksalnie ta odpowiedź będzie zaliczana do najbardziej upartych .


Artykuł zawiera przynajmniej jeden przykład idealnego przypadku użycia dla dynamicznego SQL i „nie ma czegoś takiego jak elastyczność pisania zapytań w ten sposób ...” nie jest prawdą - dynamiczny SQL jest dokładnie tym, co pozwala na to elastyczność.
LowlyDBA,

Parametry opcjonalne? Masz na myśli antywzorzec projektowy?
Forrest,

@ LowowDBA Artykuł zawiera co najmniej jeden przykład: najprostszy SELECT, jaki kiedykolwiek widziano, jaki złożony problem to rozwiązanie? i dla elastyczności, tak, dla tych naiwnych programistów.
Ivanzinho,

@ Forrest, dlaczego nazywacie to „antipattern”? ponieważ podany przez ciebie link nigdy tego nie mówi, a także nigdy nie pokazuje, jak wiele ulepszeń dokonano po przepisaniu logiki na dynamiczny SQL (co w tym przypadku byłoby nieznaczne w porównaniu do efektu kuli śnieżnej utrzymania tego zapytania w końcu)
Ivanzinho

To jest odpowiedź (słaba) oparta na opinii IMHO. Nie podałeś konkretnych przykładów problemów, które
opisujesz
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.