Почему вы хотите избежать динамического SQL в хранимой процедуре?

Я слышал, кто-то сказал, что вы не хотите использовать динамический SQL. Можете ли вы привести конкретный пример или пример из реальной жизни? Лично я несколько раз кодирую это в своей базе данных. Я думаю, что это нормально, потому что это гибкость. Я предполагаю, что SQL-инъекция или производительность. Что-нибудь еще?

Нет ничего плохого в использовании динамического SQL, если нужно. На самом деле в некоторых обстоятельствах это единственный вариант, который у вас есть. Больше рекомендуется не использовать его, так как да, это может привести к внедрению SQL, если ваш ввод не очищен, и да, использование динамического SQL в часто вызываемых модулях может отрицательно сказаться на его производительности.

Я не думаю, что как таковой есть конкретный пример, но я бы сказал так: попробуйте достичь того, что вы есть, сначала используя обычные запросы и операторы - только тогда, когда вы исчерпали все другие возможности, делайте это динамически. Просто помните, что выполнение динамической строки SQL выполняется в отдельном сеансе пользователя с вызывающим ее модулем, поэтому вы можете столкнуться с проблемами с разрешениями, когда вы их не ожидаете.

Если вы беспокоитесь о производительности; Попробуй это. Если вы беспокоитесь о безопасности; подтвердите свой вклад. Нет правильного или неправильного - только то, что вы используете свое лучшее суждение, основываясь на информации и инструментах, которые у вас есть в то время.

Динамический SQL - это инструмент. И как инструмент, у него есть несколько приложений - для административных работ это, например, благословение.

Не очень хорошо для SP, используемого приложениями, особенно если вы не управляли параметризацией сгенерированного кода (последние версии SQL Server уменьшали проблемы, но все еще действовали).

Я не буду вдаваться здесь в подробности, поэтому я рекомендую отличную статью о проблемах динамического SQL: Проклятие и благословения динамического SQL. Автор MVP Эрланд Соммарског.

Это похоже на большинство функций dbms: если вы используете его в правильной ситуации, он хорошо работает, в неправильной - плохо.

Плюсы: некоторые вещи просто невозможно сделать без этого. Обычно я обнаружил, что это только для административной работы, а не для кода приложения. Некоторые системные команды не позволяют использовать параметры в качестве входных данных. Так, например, если мне нужно выполнить что-то через sproc для каждой базы данных, во многих случаях с неизвестными базами данных, и команда не принимает параметры, я обычно решаю это с помощью динамического SQL. Однако в Sybase ASE это больше, чем MSSQL.

Минусы: я не буду вдаваться в подробности, так как я думаю, что мы все уже знаем это, но может быть некоторый риск для внедрения SQL, если он используется неправильно. Для меня более важным является то, что запрос будет обрабатываться так, как он есть, уникальный запрос adhoc, а не часть плана скомпилированного запроса. Для чего-то, что иногда работает, ничего страшного. Для чего-то, что выполняется сотни раз в минуту и ​​будет иметь много уникальных sql, это сгенерирует много новых, потенциально ненужных, планов запросов с истощением циклов и сокращением допустимого времени кэша плана.

Не используйте динамический SQL.

99% времени Динамический SQL используется из-за отсутствия знаний о том, как использовать необязательные параметры в хранимых процедурах, остальное 1% времени используется для создания очень сложного запроса для отчета, который клиент не понимает даже. Проклятие и благословения динамического SQL не показывают пример того, почему было бы неплохо использовать его, вместо этого просто предлагает, что это проблематично, потому что это усложняет отладку, обслуживание, не говоря уже о рисках безопасности SQL Внедрение, низкая производительность не потому, что кэш, а плохие методы, которые идут с ним, такие как использование временных таблиц и курсоров, которые, конечно, ленивы и наивныПрограммист будет злоупотреблять. Не существует такой вещи, как гибкость написания запросов таким образом, SQL является декларативным языком, и его следует рассматривать как таковой.

Лень - корень всего зла.

Как это ни парадоксально, но этот ответ оценивается как наиболее отрицательный .