Лучшие практики с PreparedStatements;когда и когда нет

Question

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

Я читал о том, когда использовать, а не использовать их, но ни один из примеров действительно не говорит о наилучшей практике их использования.

Я пытаюсь выяснить, для каких вызовов баз данных я должен их использовать, а для каких - нет.

Например, веб-сайт MySQL упоминает это в разделе «Когда использовать подготовленные операторы» на следующей странице Подготовленные операторы-MySQL

Answer 1

Общее правило большого пальца при принятии решения о том, идти ли за PreparedStatement или нет:

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

• Одноразовые запросы .Если ваше приложение делает один запрос к базе данных, и это делается нечасто по сравнению с другими запросами, в этом случае может не иметь смысла использовать Подготовленный оператор.Обоснование заключается в том, что предварительно подготовленный оператор должен быть сначала скомпилирован, а «скомпилированная» форма оператора кэширована для последующего использования.Для запросов, которые запускаются нечасто, компиляция является непроизводительной.Но все же, предпочтительнее использовать подготовленные операторы, чтобы избежать проблем с внедрением SQL.
• Операции с интенсивным использованием данных .Иногда подготовленные операторы не так эффективны, как хранимые процедуры, особенно когда необходимо выполнить последовательность операций в одной и той же транзакции.Если у вас есть бизнес-процесс, требующий выполнения нескольких выборок, обновлений и удалений для различных таблиц, хранимые процедуры часто лучше, чем набор подготовленных операторов, выполняемых один за другим.Это снижение производительности может стать серьезным, так как для выполнения нескольких операторов выполняется несколько сетевых отключений, что значительно уменьшается при вызове хранимой процедуры.Этот эффект более выражен в пакетной обработке запросов, когда несколько объектов создаются и уничтожаются за короткий промежуток времени.Это часто вызывает споры между администраторами баз данных и разработчиками приложений, поскольку это крайний случай;Администраторы баз данных полагают, что пакетирование операций лучше выполнять через SP, а разработчики приложений считают, что PreparedStatements могут справиться с этим (обычно лучше иметь всю логику в одном уровне).В конечном итоге все сводится к тому, что использование SP является преимуществом или нет.
• Поддержка собственных операций и типов базы данных. .Это может не сработать для MySQL, но в целом стандарт JDBC не поддерживает все операции, поддерживаемые базой данных, и все типы SQL / native / custom, поддерживаемые базой данных.Это более ярко выражено в базе данных Oracle (и, возможно, IBM DB2?), Где программисты могут создавать свои собственные типы, для которых требуется, чтобы пользовательский код Java был написан как стандарт JDBC, не поддерживающий пользовательские типы в базе данных.Точно так же другие операции в базе данных не должны поддерживаться (как говорится в документе MySQL) - нельзя создавать пользователей (выполнять CREATE USER), изменять пользовательские привилегии (выполнять операции GRANT) и т. Д., Используя Prepared Statement.Хранимые процедуры лучше подходят для этой задачи, поскольку имеют прямой или косвенный доступ к собственному набору операций базы данных.

Answer 2

PreparedStatements имеют два основных применения:

1. Предотвращение атак с использованием SQL-инъекций. Это в основном означает автоматическую очистку входных данных от внешних источников ( веб-браузер является внешним! ) которые будут сохранены в базе данных.
2. Пакетная обработка. Если у вас есть много данных для одновременного ввода / изменения в / удаления из базы данных, PreparedStatement может бытьиспользуется для этого.В этом случае PreparedStatement оптимизирует большую часть накладных расходов на такие операции и позволяет быстро написать пакетный код базы данных.

Обе эти причины являются очень убедительными и оправдывают использование PreparedStatement почти всегда, однаков зависимости от того, как вы используете базу данных, вы можете достичь точки, в которой PreparedStatement не позволит вам делать то, что вы хотите.

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

Answer 3

Для предотвращения SQL-инъекций лучше использовать подготовленные операторы в Java

Для получения дополнительной информации: SQL-инъекции с подготовленными операторами?