Динамический SQL в производственных системах

Question

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

Когда речь идет о производственных системах, следует всегда избегать динамического sql или иметь правильное место в наборе инструментов программирования. Если нет / так, почему?

Answer 1

Ответы на некоторые ваши вопросы можно найти здесь Проклятие и благословения динамического SQL

Иногда вам нужно использовать динамический SQL, потому что он будет работать лучше

Answer 2

При оценке использования динамического SQL есть несколько соображений:

• производительность может варьироваться в широких пределах и в зависимости от того, на какое ядро ​​базы данных нацелено
• обслуживание может широко варьироваться в обоих направлениях (например, динамический SQL может использовать методы модуляции, которые статический SQL не может)
• динамический SQL уязвим к атакам внедрения SQL, но статический SQL (в основном) не
• иногда ваши потребности делают статический SQL (почти) невозможным, но это должно быть редко

Помните, что SQL - это код, а RDBMS - это другой API. Это НЕ особенное или, по крайней мере, немногое; иметь дело с этим, как с любым другим кодом и API. В частности, не просто кодируйте непосредственно в API: модульный код и напишите несколько вспомогательных методов, чтобы сделать его проще и многократно использовать.

Answer 3

Это зависит от того, что вы подразумеваете под динамическим SQL. Запросы, построенные там, где значения параметров, подставляемые непосредственно в строку sql, опасны, и их следует избегать, за исключением очень редкого случая, когда нет другой опции.

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

Answer 4

Стоимость «динамического SQL» варьируется в зависимости от СУБД.

• В IBM DB2, где планы запросов могут быть предварительно скомпилированы до машинного кода, стоимость Dynamic SQL значительна.

• В IBM Informix (IDS - Informix Dynamic Server) большинство запросов фактически являются «динамическим SQL» (исключение составляют запросы в хранимых процедурах), поскольку SQL интерпретируется во время выполнения, даже если клиентский боковая запись использует статический SQL.

Я полагаю - хотя эксперт DB2 мог бы мне противоречить - что системы CLI (ODBC, также известный как CCC) и JCC (JDBC) для DB2 делают весь SQL как динамический SQL.

Я не знаю, что делают Oracle, Sybase, MS SQL Server - я подозреваю, что они ближе к линии, принятой IDS, чем линии, принятой DB2. Для MySQL и PostgreSQL я был бы удивлен, если бы они не вели себя больше как IDS, чем DB2.

В результате с IDS нет особых накладных расходов на использование динамического SQL; на уровне сервера ваш SQL в любом случае является динамическим. Другие СУБД могут иметь другие факторы в игре.

Одна проблема для всех серверов - «как вы идентифицируете предварительно скомпилированный запрос из SQL, отправленного по проводам». В DB2 прекомпиляторы идентифицируют используемый пакет, а протокол связи между приложением и сервером - это. Насколько я понимаю, клиенты DB2, такие как ODBC и JDBC, не используют предварительно скомпилированный пакет, поэтому я считаю, что они все время эффективно выполняют динамический SQL.

Остерегайтесь внедрения SQL с помощью динамического SQL!

Answer 5

В нашей системе, как мне кажется, много динамического SQL, в основном потому, что у нас много динамически создаваемых объектов (таблицы, индексы, в основном представления) Многое из этого является наследием; такие вещи, как секционированные таблицы в 2k5, помогают в некоторых случаях. Но, как уже упоминалось, вам нужно обосновать это; SQL на лету внутри проков обычно имеет лучшее (статическое) решение.

Answer 6

Динамический SQL имеет место - даже в рабочем коде. Выполнение произвольного кода с дырами в безопасности не дает.

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

Answer 7

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

Answer 8

Мой предыдущий магазин никогда не позволял бы таким вещам выполняться с базой данных (SQL Server). Это было запрещено на практике, и БД была заблокирована, чтобы предотвратить это. Вся работа проходит через объекты (ИП и т. Д.).

Это правильный способ сделать это всегда, ИМХО.