Всем привет! Сегодня хочу разобрать один из самых частых вопросов на собеседованиях и в курилках Java-команд:

«Слушай, а Hibernate вообще ещё нужен? У нас же есть Spring Data JPA, он всё делает сам».

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

Что такое Spring Data JPA на самом деле?
Многие думают, что Spring Data — это отдельная технология доступа к данным. На самом деле это просто удобная обёртка (абстракция). Когда вы пишете в репозитории `findByEmail(String email)`, Spring не магическим образом лезет в базу. За кулисами он берет реализацию, которую вы подключили. В 99% случаев этой реализацией будет Hibernate.

То есть Spring Data JPA — это руль и педали, а Hibernate — это двигатель. Одно без другого в типичном энтерпрайзе не едет.

Получается, что нужно знать Hibernate, потому что Spring Data JPA не избавляет от него, а лишь скрывает рутину. Как только вы выходите за рамки простых `findById` или `save`, абстракция начинает протекать.

Вот 5 ситуаций, где без понимания Hibernate ваше приложение просто сломается:

1. Производительность
Вы достаете 100 пользователей через `userRepository.findAll()`. У каждого пользователя есть список заказов (связь `@OneToMany`). Если вы не настроили `fetch` (например, `JOIN FETCH`), Hibernate сделает 1 основной запрос за пользователями и еще 100 дополнительных запросов в базу, чтобы достать заказы для каждого пользователя.

Почему Spring тут не поможет: Аннотация `@EntityGraph` в Spring Data — это и есть синтаксический сахар над фичами Hibernate. Чтобы правильно её написать, нужно понимать, как работает `fetch` и чем отличается `EAGER` от `LAZY`.

2. Управление транзакциями
`@Transactional` — это тоже Spring. Но что именно происходит в момент вызова `commit()`? Как работает первый и второй уровни кэша (L1/L2)? Почему данные не сохраняются, хотя метод помечен как транзакционный (например, из-за вызова приватного метода внутри того же бина)? Почему при `Propagation.NESTED` падает база? На эти вопросы отвечает архитектура Hibernate, а не Spring.

3. Оптимистичные блокировки (Optimistic Locking)
Вы добавляете `@Version` на поле. Это JPA. Но почему при параллельных запросах вылетает `OptimisticLockException`? Как именно Hibernate на уровне SQL делает `UPDATE ... WHERE version = 1`? Как это поле влияет на кэш первого уровня? Если вы не понимаете механику, вы будете ловить эти ошибки в проде и не знать, что делать.

4. Маппинг сложных данных
Вам нужно сохранить в колонку JSON, массив enum'ов или написать кастомный конвертер. Вы используете `@Convert` или `@Type` из Hibernate. Аннотации `@Column` и `@JoinColumn` тоже пришли из спецификации JPA, реализацию которой делает Hibernate, создавая `CREATE TABLE` и связывая FK. Без знания диалектов и типов данных Hibernate вы будете часами искать, почему дата сохраняется без часового пояса, а `BigDecimal` теряет точность.

5. Миграции схемы (Auto DDL)
Свойства `spring.jpa.hibernate.ddl-auto` (create, update, validate) — это настройки Hibernate. Он сам генерирует SQL для создания таблиц на основе ваших `@Entity`. Если вы не понимаете, как он строит связи и индексы, ваша база данных в тестовом окружении будет сильно отличаться от реальной структуры в проде.

Spring Data JPA — это стандарт для входа в любой современный Java-проект. Но Hibernate — это то, что отличает мидла, который просто складывает данные в базу, от сеньора, который понимает, как эти данные там лежат и почему запрос к 10 таблицам выполняется 3 секунды.