Почему хранимые процедуры редко используются?

Почему хранимые процедуры редко используются

Хранимые процедуры (Stored Procedures) — это SQL-код, хранящийся на сервере БД, но в современной разработке их используют редко. Вот основные причины:

1. Сложность версионирования и миграций

Хранимые процедуры хранятся в БД, а не в коде приложения. Это создаёт проблемы:

-- Старая версия
CREATE PROCEDURE GetUserOrders(IN userId INT)
BEGIN
  SELECT * FROM orders WHERE user_id = userId;
END;

-- Новая версия требует ALTER
ALTER PROCEDURE GetUserOrders...

В контрастном подходе вся логика миграций хранится в системе контроля версий (Git), что позволяет отслеживать изменения и откатываться.

2. Сложность тестирования

Тестирование хранимых процедур намного сложнее, чем тестирование обычного кода:

// Java код — легко тестировать
@Test
public void testGetUserOrders() {
    UserService service = new UserService(mockRepository);
    List<Order> orders = service.getUserOrders(userId);
    assertEquals(3, orders.size());
}

-- SQL процедура — сложнее
-- Нужна реальная БД или моки на уровне СУБД

Обычный код тестируется с JUnit, Mockito. Процедуры требуют dbUnit или TestContainers.

3. Привязка к конкретной БД

Основная проблема: процедуры зависят от синтаксиса конкретной СУБД:

-- MySQL
CREATE PROCEDURE proc_name() LANGUAGE SQL

-- PostgreSQL
CREATE FUNCTION proc_name() RETURNS void AS $$

-- SQL Server
CREATE PROCEDURE proc_name AS

Если нужно мигрировать БД, придётся переписывать процедуры. В Java коде с ORM это не требуется.

4. Проблемы с отладкой

Дебаgging хранимых процедур намного сложнее:

// Java — просто дебажим в IDE
public List<Order> getUserOrders(Long userId) {
    // Breakpoint здесь
    List<Order> orders = repository.findByUserId(userId);
    return orders;
}

Для процедур нужны специальные инструменты, логирование в таблицы и т.д.

5. ORM заменяет необходимость в процедурах

Современные ORM (Hibernate, JPA) решают большинство задач, которые раньше требовали процедур:

// Hibernate отлично справляется
@Repository
public interface OrderRepository extends JpaRepository<Order, Long> {
    List<Order> findByUserId(Long userId);
    
    @Query("SELECT o FROM Order o WHERE o.user.id = :userId AND o.status = :status")
    List<Order> findUserOrdersByStatus(
        @Param("userId") Long userId,
        @Param("status") String status
    );
}

6. Производительность — спорный вопрос

Хотя считается, что процедуры быстрее, на практике:

// Это тоже выполняется эффективно
List<Order> orders = entityManager.createNativeQuery(
    "SELECT * FROM orders WHERE user_id = ? AND status = ?"
).setParameter(1, userId)
 .setParameter(2, "active")
 .getResultList();

И при правильной индексации разница минимальна.

7. Контроль версий и код-ревью

Вся логика в Java коде — легче проводить code review:

// Git показывает что изменилось
public List<Order> getUserOrders(Long userId) {
    // Все изменения видны в diff
    return repository.findByUserId(userId);
}

Когда всё ещё используют процедуры?

1. Легаси системы — миграция дорога
2. Очень сложная бизнес-логика в БД — редко
3. Требования БД администратора — иногда
4. Аналитические/batch процессы — возможно

Современный подход

// Весь код в приложении (Java)
@Service
public class OrderService {
    @Transactional
    public List<Order> getUserOrdersWithDetails(Long userId) {
        User user = userRepository.findById(userId).orElseThrow();
        List<Order> orders = orderRepository.findByUserId(userId);
        
        // Вся логика видна, тестируется, версионируется
        orders.forEach(order -> {
            calculateTotals(order);
            applyDiscount(order);
        });
        
        return orders;
    }
}

Вывод: хранимые процедуры редки, потому что современный стек (Java + ORM + миграции) удобнее, безопаснее и проще в поддержке.