Ответ
Использование нативных запросов (createNativeQuery) в JPA/Hibernate даёт прямой доступ к возможностям СУБД, но сопряжено с рядом рисков и сложностей:
1. Проблемы безопасности: SQL-инъекции
- Риск: Подстановка пользовательских данных напрямую в строку запроса.
- Решение: Всегда использовать параметризованные запросы.
// НЕПРАВИЛЬНО (уязвимо)
String sql = "SELECT * FROM users WHERE name = '" + userName + "'";
// ПРАВИЛЬНО (безопасно)
Query query = em.createNativeQuery("SELECT * FROM users WHERE name = ?1");
query.setParameter(1, userName);
// Или с именованными параметрами
Query query = em.createNativeQuery("SELECT * FROM users WHERE name = :name");
query.setParameter("name", userName);2. Проблемы переносимости (Vendor Lock-in)
- Нативные запросы часто используют специфичный для СУБД синтаксис (например, оконные функции, типы данных), что привязывает приложение к конкретной базе данных.
3. Сложности с маппингом результатов
- Результат
Object[]неудобен для работы. - Маппинг на сущность (
@Entity) работает только если запрос возвращает все поля сущности в правильном порядке. - Решение: Использовать
@SqlResultSetMappingили конструктор DTO черезnewв JPQL-аналоге.
@SqlResultSetMapping(
name = "UserSummaryMapping",
classes = @ConstructorResult(
targetClass = UserSummaryDTO.class,
columns = {
@ColumnResult(name = "id", type = Long.class),
@ColumnResult(name = "name")
}
)
)4. Отсутствие автоматической оптимизации и кэширования
- Hibernate не может оптимизировать нативный запрос, как это делается с JPQL/HQL (предотвращение N+1, выбор стратегии загрузки).
- Кэш запросов второго уровня по умолчанию не применяется к нативным запросам, требуется явная настройка.
5. Потеря абстракции и усложнение поддержки
- Запросы перестают быть независимыми от схемы БД. Изменения в таблицах требуют правки строковых констант в коде.
- Усложняется тестирование (может потребоваться конкретная СУБД).
Рекомендация: Используйте нативные запросы только для сложных аналитических запросов или оптимизаций, которые невозможно выразить через JPQL/Criteria API.
Ответ 18+ 🔞
А, ну это же классика, блядь! Нативные запросы в JPA — это как взять в руки бензопилу, чтобы сделать бутерброд. Мощно? Ебать да! Но можно и пальцы поотрезать, если не знать, куда её пихать.
Смотри, вот тебе разбор полётов, почему с этой штукой надо аккуратнее, чем с тещей на похмелье.
1. Безопасность, или как не стать раздолбаем
Главная опасность — это SQL-инъекции. Это когда какой-нибудь умник через форму ввода загонит тебе ' OR '1'='1 и сольёт всю базу, а ты потом будешь чесать репу и думать, как так вышло.
// НИКОГДА, СУКА, ТАК НЕ ДЕЛАЙ! Это приглашение для любого долбоёба.
String sql = "SELECT * FROM users WHERE name = '" + userName + "'";
// А вот так — правильно, как учила мама. Параметризованный запрос.
Query query = em.createNativeQuery("SELECT * FROM users WHERE name = ?1");
query.setParameter(1, userName);
// Или с именованными параметрами, чтоб понятнее было.
Query query = em.createNativeQuery("SELECT * FROM users WHERE name = :name");
query.setParameter("name", userName);2. Привязка к базе, или vendor lock-in нахуй Начинаешь использовать какие-нибудь специфичные для PostgreSQL оконные функции или хитрые типы данных в Oracle — и всё, приехали. Менять базу потом будет охренеть как сложно. Твой код превращается в одного большого заложника конкретной СУБД.
3. Маппинг результатов — отдельная песня охуения
Вернёт тебе Hibernate массив Object[], и сиди там, как дурак, разбирай, что в каком индексе лежит. Пиздец, а не работа.
Хочешь мапить на сущность? Пожалуйста, но только если запрос возвращает ВСЕ поля ровно в том порядке, в каком они объявлены в ентити. Одно поле пропустил — получи в жопу MappingException.
Спасение — это @SqlResultSetMapping. Замудрённо, конечно, но работает.
@SqlResultSetMapping(
name = "UserSummaryMapping",
classes = @ConstructorResult(
targetClass = UserSummaryDTO.class,
columns = {
@ColumnResult(name = "id", type = Long.class),
@ColumnResult(name = "name")
}
)
)4. Оптимизация и кэширование — прощай, мой друг! Hibernate смотрит на твой нативный запрос как баран на новые ворота. Он не может его проанализировать, чтобы предотвратить проблему N+1 или как-то хитро подгрузить связанные данные. Всё ложится на твои плечи.
Кэш запросов второго уровня? Забудь, по умолчанию он тут не работает. Надо танцевать с бубном и явно его включать.
5. Потеря абстракции и ад поддержки Ты пишешь запросы как строки. Изменилась структура таблицы — иди и вручную ищи все эти строки в коде, как иголку в стоге сена. Тестирование превращается в пиздец — нужна уже конкретная база, а не in-memory H2.
Так что же делать, ёпта? Используй эту бандитскую отмычку только тогда, когда без неё реально никак. Сложные аналитические запросы, которые в JPQL не впихнуть, или точечная оптимизация, от которой зависит жизнь и смерть приложения. Во всех остальных случаях — JPQL или Criteria API. Не усложняй себе жизнь, чувак.