Приведи пример, когда использование нативного SQL оправдано

Приведи пример, когда использование нативного SQL оправдано

Когда ORM становится узким местом

ORM-фреймворки (Hibernate, JPA) отлично работают для стандартных CRUD операций, но есть сценарии, где чистый SQL критичен для производительности и функциональности.

Примеры из реальной практики

1. Аналитические запросы со сложной агрегацией

Когда нужны запросы с множественной группировкой, оконными функциями и условной логикой:

// ❌ ORM подход - неэффективно
List<Order> orders = orderRepository.findAll();
Map<String, BigDecimal> result = orders.stream()
    .filter(o -> o.getCreatedDate().isAfter(startDate))
    .collect(Collectors.groupingBy(
        o -> o.getCategory(),
        Collectors.summingBigDecimal(Order::getAmount)
    ));

// ✅ Нативный SQL - быстро и правильно
String query = "SELECT category, DATE_TRUNC('month', created_date) AS month, SUM(amount) AS total_amount, COUNT(*) AS order_count FROM orders WHERE created_date >= :startDate GROUP BY category, DATE_TRUNC('month', created_date) HAVING COUNT(*) > 10 ORDER BY total_amount DESC";

List<Object[]> results = entityManager
    .createNativeQuery(query)
    .setParameter("startDate", startDate)
    .getResultList();

Почему: ORM вытащит ВСЕ заказы в память, а затем фильтрует. SQL все сделает в БД.

2. Операции с полнотекстовым поиском

Полнотекстовый поиск требует специальных индексов и функций БД:

// ❌ Неправильно - LIKE слишком медленно на больших таблицах
List<Article> articles = articleRepository.findByTitleContainingIgnoreCase(query);

// ✅ Нативный SQL с полнотекстовым поиском (PostgreSQL)
String query = "SELECT a.* FROM articles a WHERE to_tsvector('russian', a.title) @@ plainto_tsquery('russian', :searchQuery) ORDER BY ts_rank(to_tsvector('russian', a.content), plainto_tsquery('russian', :searchQuery)) DESC LIMIT 50";

List<Article> results = entityManager
    .createNativeQuery(query, Article.class)
    .setParameter("searchQuery", searchQuery)
    .getResultList();

Почему: PostgreSQL имеет встроенные оптимизированные функции полнотекстового поиска.

3. Массовые обновления и удаления

Большие UPDATE/DELETE операции нельзя делать через ORM:

// ❌ ORM подход - выгружает все записи в память
List<UserSession> sessions = sessionRepository.findByExpiresBefore(now);
sessions.forEach(session -> sessionRepository.delete(session));
// flush() - вызовет N DELETE запросов

// ✅ Одна операция в БД
String query = "DELETE FROM user_sessions WHERE expires_at < :now AND status = 'inactive'";

int deleted = entityManager
    .createNativeQuery(query)
    .setParameter("now", LocalDateTime.now())
    .executeUpdate();

Результат: 1 SQL запрос вместо 10 000 DELETE операций.

4. Вычисление сложных бизнес-логики в БД

Когда логика зависит от данных, которые проще вычислить SQL:

// ❌ Java логика - множество запросов
User user = userRepository.findById(userId).orElseThrow();
List<Order> orders = orderRepository.findByUserId(userId);
List<Review> reviews = reviewRepository.findByUserId(userId);
int loyaltyScore = calculateLoyalty(orders, reviews);

// ✅ Все в одном запросе
String query = "SELECT u.id, u.email, COUNT(o.id) AS total_orders, COALESCE(SUM(o.amount), 0) AS lifetime_value, CASE WHEN SUM(o.amount) > 10000 THEN 'platinum' WHEN SUM(o.amount) > 5000 THEN 'gold' ELSE 'regular' END AS tier FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE u.id = :userId GROUP BY u.id, u.email";

Object[] result = (Object[]) entityManager
    .createNativeQuery(query)
    .setParameter("userId", userId)
    .getSingleResult();

5. Использование специфичных функций БД

Каждая БД имеет уникальные возможности:

// PostgreSQL - рекурсивный CTE для иерархий
String query = "WITH RECURSIVE category_tree AS (" +
    "SELECT id, name, parent_id, 0 AS level FROM categories WHERE parent_id IS NULL " +
    "UNION ALL " +
    "SELECT c.id, c.name, c.parent_id, ct.level + 1 FROM categories c " +
    "JOIN category_tree ct ON c.parent_id = ct.id" +
    ") SELECT * FROM category_tree WHERE level <= 3 ORDER BY level, name";

// MySQL - JSON функции
String query = "SELECT id, data->>'$.name' AS name FROM products WHERE JSON_CONTAINS(data, '\"electronics\"')";

Как правильно использовать нативный SQL

@Repository
public class AnalyticsRepository {
    @PersistenceContext
    private EntityManager entityManager;
    
    public List<SalesReport> getMonthlyReport(LocalDate startDate) {
        String query = "SELECT ..."; // SQL запрос
        return entityManager.createNativeQuery(query, SalesReport.class)
            .setParameter("startDate", startDate)
            .getResultList();
    }
}

Когда НЕ использовать нативный SQL

• Простые CRUD - используй ORM (проще, безопаснее)
• Часто меняющаяся логика - сложнее тестировать и поддерживать
• Критичная переносимость между разными БД

Резюме

Нативный SQL оправдан:

• Сложные аналитические запросы с GROUP BY и агрегацией
• Полнотекстовый поиск
• Массовые операции (bulk update/delete) на миллионах записей
• Использование специфичных функций БД (оконные функции, JSON, иерархии)
• Когда нужна максимальная производительность

Правило: Используй ORM для основной логики, нативный SQL только для специальных случаев.