Я должен использовать PreparedStatements для всей своей базы данных, вставляет в Java?
Ваш шаблон закрыт неправильно: я вижу < шаблон> вместо < / template>.
5 ответов
Да, используйте подготовленные операторы для всего.
Они анализируются однажды.
Они неуязвимы для атак с использованием кода на SQL.
Они - лучший дизайн, потому что необходимо думать о SQL и как он используется.
Если Вы думаете, что они только используются однажды, Вы не смотрите на большое изображение. Однажды, Ваши данные или Ваше приложение изменятся.
Править.
Почему подготовленные операторы заставляют Вас думать о своем SQL?
Когда Вы собираете строку (или просто выполните литеральный блок текста), Вы не создаете новое
PreparedStatementобъект. Вы просто выполняете SQL - он может быть сделан очень небрежно.Когда необходимо создать (и сохранить), a
PreparedStatement, необходимо думать просто крошечный бит больше об инкапсуляции, выделении ответственности. Подготовка оператора является событием с сохранением информации до выполнения любой обработки SQL.
Дополнительная работа является маленькой, но весьма значительной. Это - то, что заставляет людей начинать думать о ORM и слое кэширования данных и подобных вещах оптимизировать их доступ к базе данных.
С Подготовленными операторами доступ к базе данных является менее случайным, более намеренным.
Подготовка оператора не является настолько дорогой. Это более безопасно, чем большинство альтернатив.
Вы никогда не должны создавать SQL-запрос сами с помощью конкатенации строк. Вы никогда не должны вручную выходить из данных переменных/пользователя при построении SQL-запроса. Фактический выход, который требуется, варьируется в зависимости от Вашей базовой базы данных, и в какой-то момент кто-то забудет выходить.
Точка - это: с подготовленными операторами невозможно создать SQL вводимый оператор. С пользовательским выходом это возможно. Выбор очевиден.
Я услышал аргумент, что PreparedStatement стоит небольших дополнительных издержек по простому Оператору, и что должно быть безопасно, если я не связываю ввод данных пользователем в свой запрос. Это может быть верно, но дополнительные расходы не так очень, и SQL-запросы изменяются со временем. Если Вы начинаете использовать Оператор сегодня, потому что Вы доказали себе, что Ваш запрос инжекционно-защищен, Вы собираетесь для отказа в день, что программист обслуживания изменяет SQL для принятия ввода данных пользователем, но не думает для изменения того Оператора на PreparedStatement. Мой совет состоит в том, чтобы всегда использовать PreparedStatement для препятствия проблеме, прежде чем это найдет Вас.
Еще лучше не используйте API JDBC непосредственно, потому что это так подвержено ошибкам (например, не удающийся правильно очистить все ресурсы во всех случаях). Используйте объект помощника JDBC, такой как интерфейс JdbcOperations Spring, который значительно уменьшает размер и ошибочность Вашего кода. Если Вы только используете, Кидаются за этой функцией, Вы все еще сделали себе серьезное одолжение по сравнению с использованием API JDBC непосредственно.