Ответ
Да, работал с хранимыми процедурами. Это предкомпилированные блоки SQL-кода, хранящиеся на стороне СУБД.
Преимущества:
- Производительность: План выполнения кэшируется СУБД.
- Снижение сетевого трафика: Вместо нескольких запросов отправляется один вызов.
- Безопасность и абстракция: Клиентскому коду не видна структура таблиц, можно контролировать доступ.
- Централизация логики: Изменения вносятся в одном месте (БД).
Недостатки:
- Привязка к вендору: Синтаксис отличается между PostgreSQL, Oracle, MySQL.
- Сложность отладки и тестирования.
- Может нарушать принцип разделения ответственности, если содержит сложную бизнес-логику.
Вызов из Java с использованием JDBC (CallableStatement):
// Процедура: CREATE PROCEDURE get_employee(IN emp_id INT, OUT emp_name VARCHAR(255))
String sql = "{call get_employee(?, ?)}"; // Синтаксис вызова
try (Connection conn = dataSource.getConnection();
CallableStatement stmt = conn.prepareCall(sql)) {
// Установка входных (IN) параметров
stmt.setInt(1, employeeId);
// Регистрация выходных (OUT) параметров
stmt.registerOutParameter(2, Types.VARCHAR);
// Выполнение процедуры
stmt.execute();
// Получение значения выходного параметра
String employeeName = stmt.getString(2);
System.out.println("Employee: " + employeeName);
} catch (SQLException e) {
// Обработка ошибок
}Вызов через JPA (Hibernate):
@PersistenceContext
private EntityManager entityManager;
StoredProcedureQuery query = entityManager
.createStoredProcedureQuery("get_employee")
.registerStoredProcedureParameter(1, Integer.class, ParameterMode.IN)
.registerStoredProcedureParameter(2, String.class, ParameterMode.OUT)
.setParameter(1, employeeId);
query.execute();
String employeeName = (String) query.getOutputParameterValue(2);Когда использовать: Для сложных атомарных операций с данными, критичных по производительности, или когда логика должна быть доступна для разных приложений, работающих с одной БД.
Ответ 18+ 🔞
А, хранимки, блядь! Ну, это типа как заготовленные консервы в погребе базы данных, а не каждый раз на кухне готовить.
Что хорошего, ёпта:
- Гонит быстрее: Сервер базы один раз подумал, как это выполнять, и план в кэш засунул. Больше не парится.
- Меньше болтать по сети: Вместо кучи мелких запросов — один чёткий вызов, типа «дай то, не знаю что».
- Безопасность и скрытность: От клиента спрятано, какие там таблицы и как они ебутся между собой. Доступ можно настрогать.
- Всё в одной бочке: Логика в одном месте живёт. Поменял в процедуре — и на всех клиентах сразу, в рот меня чих-пых!
А теперь дерьмо, которое вылезает:
- Привязан к конкретной СУБД, как маньяк к жертве: Написал под Oracle — попробуй это в PostgreSQL запустить, получишь сплошной пиздец. Синтаксис везде разный.
- Отлаживать и тестировать — просто жесть. Не то что обычный код.
- Может нахутарить бардака в архитектуре, если начнёшь туда всю бизнес-логику пихать. База данных — не место для таких танцев с бубном.
Как вызвать эту дичь из Java через старый добрый JDBC:
// Допустим, процедура на стороне: CREATE PROCEDURE get_employee(IN emp_id INT, OUT emp_name VARCHAR(255))
String sql = "{call get_employee(?, ?)}"; // Вот такой, блядь, фирменный синтаксис вызова
try (Connection conn = dataSource.getConnection();
CallableStatement stmt = conn.prepareCall(sql)) {
// Засовываем входной (IN) параметр
stmt.setInt(1, employeeId);
// Говорим, мол, жди отсюда ответ (OUT параметр)
stmt.registerOutParameter(2, Types.VARCHAR);
// Поехали, блядь!
stmt.execute();
// Вытаскиваем, что нам там навыходили
String employeeName = stmt.getString(2);
System.out.println("Employee: " + employeeName);
} catch (SQLException e) {
// Ну тут всё ясно, ебать-колотить
}А если ты изнеженный и через JPA (Hibernate) хочешь:
@PersistenceContext
private EntityManager entityManager;
StoredProcedureQuery query = entityManager
.createStoredProcedureQuery("get_employee")
.registerStoredProcedureParameter(1, Integer.class, ParameterMode.IN)
.registerStoredProcedureParameter(2, String.class, ParameterMode.OUT)
.setParameter(1, employeeId);
query.execute();
String employeeName = (String) query.getOutputParameterValue(2);Когда это вот всё применять? Ну, когда у тебя есть какая-то ебейшая атомарная операция с данными, где каждый миллисекунд на счету. Или когда одна и та же логика должна торчать из разных приложений в одну и ту же базу. В остальных случаях — подумай десять раз, не проще ли обычным кодом, а то потом будешь кусать локти, ёпта.