Я чув, як один сказав, що ви не хочете використовувати Dynamic SQL. Чи можете ви навести якийсь конкретний приклад чи приклад із реального життя? Особисто я кодую це кілька разів у своїй базі даних. Я думаю, що це нормально, тому що це гнучкість. Моя здогадка стосується інжекцій або продуктивності SQL. Ще щось?
Відповіді:
Немає нічого поганого в використанні динамічного SQL, якщо потрібно. Насправді за деяких обставин це єдиний варіант, який у вас є. Більше рекомендується не використовувати його, оскільки так, це може призвести до ін'єкції SQL, якщо ваш вклад не буде дезінфікований, і так, використовуючи динамічний SQL в модулях, які часто викликаються, може бути згубним для його продуктивності.
Я не думаю, що конкретного прикладу як такого є, але я б сказав це: спробуйте досягти того, що ви є після використання звичайних запитів і заяв спочатку - лише потім, коли ви вичерпали всі інші шляхи, робіть це динамічно. Пам'ятайте лише, що виконання динамічного рядка SQL виконується в окремому сеансі користувача до модуля, який його викликає - так що ви можете зіткнутися з проблемами дозволів, де ви їх не очікуєте.
Якщо ви переживаєте за продуктивність; перевірити його. Якщо ви переживаєте за безпеку; підтвердити ваш внесок. Немає правильного чи неправильного - лише ви користуєтесь своїм найкращим судженням, виходячи з інформації та інструментів, які вам були доступні на той момент.
Динамічний SQL - це інструмент. І як інструмент, він має деякі програми - наприклад, для адміністративних робіт це благо.
Не так добре для SP, що використовується програмами, особливо якщо ви не керували параметризацією згенерованого коду (останні версії SQL Server зменшили проблеми, але все ще дійсні).
Я не буду тут детально входити, тому рекомендую чудову статтю про питання динамічних SQL: Прокляття та благословення динамічного SQL від MVP Ерланда Соммарського.
Це як у більшості функцій dbms, якщо ви користуєтесь ним у правильній ситуації, це добре справляється, неправильна ситуація - це погано.
Плюси: деякі речі просто не обійтися без цього. Зазвичай я вважаю, що це стосується лише адміністративної роботи, а не коду програми. Деякі системні команди не дозволяють використовувати параметри як вхідні дані. Так, наприклад, якщо мені потрібно запустити щось через відросток проти кожної бази даних, у багатьох випадках з невідомими базами даних, і команда не приймає параметри, я зазвичай вирішую це через динамічний SQL. Однак це більше у Sybase ASE, ніж у MSSQL.
Мінуси: Я не буду надто багато в цьому займатися, оскільки, думаю, ми всі це вже знаємо, але може бути певний ризик введення SQL, якщо він використовується неправильно. Більш великий для мене полягає в тому, що запит буде розглядатися як такий, який він є, унікальний запит adhoc, а не частина складеного плану запитів. Щось те, що спрацьовує зрідка, не має нічого особливого. Що-небудь, що виконується сотні разів на хвилину, і це матиме багато унікальних sql, це створило б багато нових, потенційно непотрібних планів запитів, з'їдання циклів, і скорочення дійсного часу кешу плану.
Не використовуйте Dynamic SQL.
99% часу використовується Dynamic SQL через брак знань про використання необов'язкових параметрів у збережених процедурах, решта 1% часу використовується для створення дуже складного запиту для звіту, який клієнт не розуміє навіть. Curse and Blessings of Dynamic SQL не показує приклад того, чому було б корисно його використовувати, натомість просто підказує, що це проблематично, оскільки це збільшує складність налагодження, підтримання, не кажучи вже про ризики безпеки SQL Ін'єкція, низька продуктивність не тому, що кеш, але погані практики, які пов'язані з ним, як використання тимчасових таблиць і курсорів, що, звичайно, лінивий і наївнийпрограміст зловживав би. Не існує такої можливості, як гнучкість писати запити таким чином, SQL - це декларативна мова, і її слід розглядати як таку.
Лінь - корінь усього зла.
Парадоксально, але ця відповідь буде віднесена до найбільш прихильних .