Оставил бы хранимые процедуры, если бы они занимали меньше места

Причины избегать хранимых процедур в современной архитектуре

Несмотря на потенциальную экономию памяти, я бы не рекомендовал использовать хранимые процедуры в современных Java приложениях. Вот почему:

Снижение переносимости кода

Хранимые процедуры привязывают приложение к конкретной СУБД. Если написана процедура для PostgreSQL, она не будет работать в MySQL или Oracle без значительных переделок. В Java приложениях мы стремимся абстрагировать работу с БД, чтобы можно было менять СУБД без изменения основного кода.

// Плохо — зависимость от конкретной БД
Session session = sessionFactory.openSession();
Query query = session.createNativeQuery("{CALL calculate_discount(?)}")
    .addEntity(Order.class);

Усложнение тестирования

Хранимые процедуры сложно тестировать в изоляции. Для unit-тестов нужна запущенная БД, а для интеграционных тестов требуется сложная подготовка окружения. JPA/Hibernate позволяют легко мокировать работу с БД:

// Хорошо — легко тестируется
@Repository
public class OrderRepository {
    public BigDecimal calculateDiscount(Order order) {
        return order.getPrice().multiply(
            BigDecimal.valueOf(1 - order.getCustomer().getDiscountRate())
        );
    }
}

Разделение ответственности

Бизнес-логика должна быть в application layer (Java код), а не распылена между приложением и СУБД. Это нарушает принципы Clean Architecture и DDD, делает код сложнее поддерживать и эволюционировать.

Проблемы с версионированием

Хранимые процедуры часто забывают задокументировать и версионировать должным образом. При изменении схемы БД легко забыть обновить процедуру, что приведёт к несоответствению между кодом и реальным поведением.

Альтернатива: ORM и JPQL

Обычно нужное оптимизируется проще через Hibernate/JPA:

// Вместо хранимой процедуры
@Entity
public class Order {
    @Id
    private UUID id;
    
    @ManyToOne
    private Customer customer;
    
    private BigDecimal price;
}

@Repository
public class OrderRepository extends JpaRepository<Order, UUID> {
    @Query("SELECT o FROM Order o WHERE o.customer.id = ?1")
    List<Order> findByCustomer(UUID customerId);
}

Когда хранимые процедуры оправданы

Замечу честно: есть редкие случаи, когда без них не обойтись:

• Крайне сложные аналитические запросы с множеством JOIN и оконных функций
• Массовые операции где нужна максимальная производительность на уровне БД
• Миграция legacy-систем, где процедуры уже есть и переписать их нецелесообразно

Но даже в этих случаях я бы оставил процедуру только на уровне БД, а из Java обращался к ней через ORM с явным контрактом.

Вывод

Минимизация памяти хранимых процедур — не стоит той цены, которую приходится платить в виде снижения переносимости, усложнения тестирования и нарушения архитектуры. Современные ORM и СУБД оптимизируют JPQL-запросы достаточно эффективно для большинства случаев.