Там оборотные стороны к использованию подготовленных операторов?
Создайте решение, закройте его, поместите файлы, где Вы хотите их и редактируете sln.
4 ответа
Подготовленный оператор - это просто проанализированный и предварительно скомпилированный оператор SQL , который просто ожидает, пока будут предоставлены связанные переменные для выполнения .
Любой выполненный оператор рано или поздно становится подготовленным (его необходимо проанализировать, оптимизировать, скомпилировать и затем выполнить).
Подготовленный оператор просто повторно использует результаты синтаксического анализа, оптимизации и компиляции.
Обычно системы баз данных используйте некоторую оптимизацию, чтобы сэкономить время на подготовке запроса, даже если вы сами не используете подготовленные запросы.
Oracle , например, при синтаксическом анализе запроса сначала проверяет кеш библиотеки, и если тот же оператор имел уже проанализирован, вместо этого используется кешированный план выполнения.
Если вы используете оператор только один раз или автоматически генерируете динамические операторы sql (и либо правильно экранируете все, либо точно знаете, что ваши параметры содержат только безопасных символов ), тогда вам не следует использовать подготовленные операторы.
Там Еще одна небольшая проблема с подготовленными операторами и динамическим sql, а именно то, что их может быть сложнее отлаживать. С динамическим sql вы всегда можете просто записать проблемный запрос в файл журнала и запустить его прямо на сервере точно так, как его видит ваша программа. С подготовленными операторами может потребоваться немного больше работы для тестирования вашего запроса с определенным набором параметров, определенных на основе данных о сбоях. Но не более того, и дополнительная безопасность определенно оправдывает затраты.
Единственный недостаток, о котором я могу думать, это то, что они занимают память на сервере. Это не так уж и много, но, вероятно, есть некоторые крайние случаи, когда это может стать проблемой, но мне трудно думать о чем-либо.