Динамичният SQL и съхранените процедури са два от най-важните компоненти на SQL Server. В тази статия ще разгледаме предимствата и недостатъците на всеки от тях и кога да ги използвате.
Ефективност
Всеки знае отговора на този въпрос. Съхранените процедури превъзхождат динамичния SQL по отношение на производителността. Съхранената процедура се кешира в паметта на сървъра и нейното изпълнение е много по-бързо от динамичния SQL. Ако всички останали променливи се поддържат постоянни, съхранената процедура превъзхожда динамичния SQL.
Разделяне на загрижеността
По отношение на разделянето на проблемите, съхранените процедури надминават динамичния SQL.
Съхранените процедури ви позволяват да поддържате логиката на вашата база данни отделно от вашата бизнес логика. Следователно, ако възникне грешка във вашата бизнес логика, трябва само да промените кода на приложението си. Обратно, ако има проблем с логиката на вашата база данни, само вашата съхранена процедура трябва да бъде променена. Освен това, ако съхранена процедура се актуализира, не е необходимо кодът на приложението да се компилира и внедрява повторно.
Ако използвате динамични SQL заявки във вашия клиентски код, ще трябва да актуализирате кода на приложението, ако възникне грешка в SQL заявката. Това означава, че ще трябва да прекомпилирате и разположите кода на приложението.
Мрежов трафик
Съхранените процедури произвеждат по-малко мрежов трафик от динамичния SQL, тъй като изпълнението на съхранена процедура изисква само името на процедурата и параметрите (ако има такива), които да бъдат изпратени по мрежата.
Изпълнението на динамичен SQL изисква пълната заявка да бъде изпратена в мрежата, увеличавайки мрежовия трафик, особено ако заявката е много голяма.
Атаки с инжектиране на SQL
Съхранените процедури не са уязвими към атаки с инжектиране на SQL.
Динамичните SQL заявки са уязвими към атаки с инжектиране на SQL, ако не се използват параметризирани заявки, а параметризираните заявки не могат да се използват с динамичен SQL, ако името на таблица или колона се предава като параметър.
В този случай решението е, че функцията за кодово име може да се използва за предотвратяване на атаки с инжектиране на SQL.
Повторна употреба на кеширани планове за заявки
Съхранените процедури подобряват производителността на базата данни, тъй като позволяват повторно използване на кеширани планове за заявки. В случай на динамичен SQL ще трябва да използвате параметризирани заявки, за да увеличите повторното използване на кеширания план за заявки. При липса на параметризирани планове за заявки, SQL сървърът автоматично открива параметри и генерира кеширани планове за заявки, което води до подобрена производителност.
Тук е уместно да се спомене, че само OLTP системите се възползват от повторното използване на кеширания план за заявки. В случай на OLAP системи, изборът на оптимизатор се променя, OLAP системата се възползва от уникалния план.
Поддръжка
Съхранените процедури със статичен SQL са по-лесни за поддръжка. Например, в случай на статичен SQL в съхранена процедура, синтактични грешки могат да бъдат уловени, преди да бъдат изпълнени. В случай на динамичен SQL вътре в съхранените процедури, синтактични грешки не могат да бъдат уловени преди изпълнението на заявката.
Освен това, съхранените процедури са по-скоро функции, те се дефинират веднъж и след това могат да бъдат извикани навсякъде в скрипта. Следователно, ако искате да актуализирате съхранена процедура, трябва да я актуализирате само на едно място. Всички части на приложението, извикващи съхранената процедура, ще имат достъп до актуализираната версия. Недостатъкът обаче е, че тези части на приложението също могат да бъдат засегнати, когато не искате актуализираната съхранена процедура. В случай на динамичен SQL може да се наложи да пишете SQL скрипт на няколко места, но в такива случаи актуализирането на скрипт на едно място не засяга другото. Решението между използване на съхранена процедура и динамичен SQL зависи от функционалността на приложението.
Сигурност
Ако множество приложения имат достъп до база данни, е по-сигурно да се използват съхранени процедури от динамичния SQL.
Съхранените процедури осигуряват допълнителен слой сигурност, докато потребителският контекст е единственият начин за контрол на разрешенията за динамични SQL скриптове. Като цяло, осигуряването на динамичен SQL е трудоемко в сравнение със съхранените процедури.
Идентифициране на зависимости
В релационна база данни таблиците имат зависимости от други таблици в базата данни.
Помислете за сценарий, при който искате да премахнете таблица, но преди да направите това, искате да разберете всички зависимости на таблицата. Или по-просто казано, искате да намерите заявките, които имат достъп до таблицата, която искате да изтриете. В тези случаи можете да използвате съхранената процедура sp_depends.
Въпреки това, sp_depends може да открие само онези зависимости, при които се използва статичен SQL в съхранена процедура. В случай, че динамичният SQL зависи от таблица, тази зависимост не може да бъде открита от съхранената процедура sp_depends. Нека видим това в действие с помощта на прост пример.
Подготовка на фиктивни данни
Нека създадем някои фиктивни данни, за да обясним концепцията за зависимостите в статичен и динамичен SQL.
CREATE DATABASE deptest;ИЗПОЛЗВАЙТЕ deptestCREATE TABLE student( Id int identity първичен ключ, Име VARCHAR(50) NOT NULL, Пол VARCHAR(50) NOT NULL, Age int)INSERT INTO studentVALUES('James', 'Male', 20 ),('Helene', 'Female', 20),('Sofia', 'Female', 20),('Ed', 'Male', 20),('Ron', 'Female', 20)
Сега имаме тестова база данни, съдържаща таблица и някои тестови данни. Сега нека създадем две съхранени процедури, които имат достъп до таблицата на учениците.
Първата съхранена процедура използва статичен SQL за извличане на всички записи от таблицата на учениците:
ИЗПОЛЗВАЙТЕ deptestGOCREATE PROC spStatProcASBEGIN SELECT * ОТ ученикEND
Изпълнете скрипта по-горе. Този скрипт създава съхранена процедура „spStatProc“ в най-дълбоката база данни.
Нека създадем друга съхранена процедура, която съдържа динамичен SQL, който извлича всички записи от таблицата на студентите.
ИЗПОЛЗВАЙТЕ deptestGOCREATE PROC spDynProcASBEGIN DECLARE @query NVARCHAR(100) SET @query ='SELECT * FROM student' EXECUTE sp_execute @query END
Този скрипт създава съхранена процедура „spDynProc“ в най-дълбоката база данни. Тази съхранена процедура използва динамичен SQL израз за извличане на всички записи от таблицата на учениците.
Сега имаме две съхранени процедури, които имат зависимост от таблицата на студентите. Единият от тях съдържа статичен SQL, а другият съдържа динамичен SQL.
Ако обаче изпълните съхранената процедура sp_depends и й предадете таблицата на студентите като параметър, ще видите, че тя ще извлече само съхранената процедура „spStatProc“. Това е така, защото съдържа статичен SQL. Съхранената процедура „spDynProc“ ще бъде игнорирана, тъй като съдържа динамичен SQL.
Изпълнете следния скрипт.
ИЗПОЛЗВАЙТЕ deptestGOEXECUTE sp_depends student
Той ще получи следния изход:
[table id=40 /]
Можете да видите, че sp_depends не е успял да докладва зависимостта „spDynProc“ и е докладвал само „spStatProc“.
Сложност
Съхранените процедури могат да станат изключително сложни, ако използвате голям брой филтри и има множество клаузи И и ИЛИ между филтрите. От друга страна, използвайки динамичен SQL, можете динамично да генерирате клаузи WHERE в зависимост от типа на филтрите. Това прави динамичния SQL по-добрият избор, ако искате да приложите изключително сложна логика.
Заключение
Като цяло съхранената процедура превъзхожда динамичния SQL в почти всички аспекти. Те са по-бързи, сигурни и лесни за поддръжка и изискват по-малко мрежов трафик. Като правило, съхранените процедури трябва да се използват в сценарии, при които не е нужно да променяте заявките си и вашите заявки не са много сложни. Въпреки това, ако често променяте имена на таблици, имена на колони или броя на параметрите във вашата заявка, Dynamic SQL е по-добрият избор поради по-опростената си стратегия за внедряване.
Полезни връзки
- Динамичен SQL срещу съхранени процедури
- Не се страхувайте от динамичния SQL
- Създаване на високопроизводителни съхранени процедури
- Класове за съхранени процедури
