Вашият примерен код е толкова прост, че ще има малка разлика, но в този случай статичната версия най-вероятно ще се изпълнява по-добре.
Основната причина да използвате динамичен SQL за производителност е, когато SQL изразът може да варира значително - т.е. може да сте в състояние да добавите допълнителен код към клаузата WHERE по време на изпълнение въз основа на състоянието на системата (ограничаване чрез подзаявка на адрес, ако е въведен адрес и т.н.).
Друга причина е, че понякога използването на Bind променливи като параметри може да бъде контрапродуктивно.
Пример е, ако имате нещо като поле за състояние, където данните не са равномерно разпределени (но са индексирани).
Помислете за следните 3 твърдения, когато 95% от данните са „P“обработени
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
В окончателната версия Oracle ще избере общ план за обяснение. В първата версия може да реши, че най-добрият план е да започне с индекса на състоянието (като се знае, че „необработените записи са много малка част от общия брой).
Можете да приложите това чрез различни статични изрази, но когато имате по-сложни изрази, които се променят само с няколко знака, динамичният SQL може да е по-добър вариант.
Недостатъци
Всяко повторение на един и същ динамичен SQL оператор води до мек синтактичен анализ, който е малък режий в сравнение със статичен израз, но все пак излишък.
Всеки НОВ оператор sql (динамичен или статичен) също води до заключване на SGA (споделена памет) и може да доведе до изтласкване на „стари“ оператори.
Лош, но често срещан дизайн на системата е някой да използва динамичен SQL за генериране на прости избори, които варират само по ключ - т.е.
SELECT col FROM table WHERE id = 5
SELECT col FROM table WHERE id = 20
SELECT col FROM table WHERE id = 7
Отделните изявления ще бъдат бързи, но цялостната производителност на системата ще се влоши, тъй като убива споделените ресурси.
Освен това - много по-трудно е да се хванат грешки по време на компилиране с динамичен SQL. Ако използвате PL/SQL, това изхвърля добрата проверка на времето за компилация. Дори когато използвате нещо като JDBC (където премествате целия си код на базата данни в низове - добра идея!), можете да получите предварителни анализатори за валидиране на съдържанието на JDBC. Динамичен SQL =само тестване по време на изпълнение.
Режийни разходи
Разходите за незабавно изпълнение са малки - те са в хилядни от секундата - обаче могат да се сумират, ако това е вътре в цикъл / на метод, извикан веднъж на обект / и т.н. SQL с генериран статичен SQL. Това обаче усложни кода и беше направено само защото ни беше необходима скоростта.
