JDBC vs JPA

[rdo]

Не знаю, почему в статьях про JPA ВСЕ авторы набрасываются на "страшные, неоптимизированные запросы, которые выполняются по десять минут и кладут базу данных", но никогда не упоминают, что JPA избавляет от надобности писать однотипные select where и update where на каждый чих при работе с БД.

Запросы, которыми может подавиться jpa в типичных энтерпрайзных приложениях составляют не более пары процентов от типовых операций "достать из бд сущность и обносить ее данными из пришедшего json"

[petejones83]

Проблема с JPA в том, что он может внезапно накинуть 2-3 запроса сверху, в зависимости от графа сущностей. Там, где кажется, что должен быть один запрос, легко может быть пять.

Есть неплохая библиотека, чтобы защититься от такого, она позволяет убедиться, что такой-то запрос выполняет 2 селекта, а не 10 https://github.com/quick-perf/quickperf

[bay73]

Написать много однотипных select where и update where проблемы не составляет. А вот лечить приложение, которое умерло из-зв того, что ленивые разработчики положились на JPA и не потестировали его на реальных данных - это реальная проблема. И даже на один такой кривой запрос уходит намного больше сил и времени (к тому же высококвалифицированного), чем на написание сотни однотипных запросов.

[St_one]

Плюс есть jooq, который сильно упрощает написание запросов. А запросы писать придется в любом случае, даже с hibernate.

[gsaw]

Нынче зарплату платить дороже разработчикам, чем железо оплачивать или потом посадить спеца и все оптимизировать. Сейчас важно быстрее выдать результат. И jpa упрощает все. Написал контейнер с данными и магия начинает работать. Разработчик концентрируется на логике больше, чем на приземленном.

[NotDie]

Совершенно не согласен. Давайте представим, у вас есть боевое приложение монолит, которое должно отрабатывать в какие-то временные рамки каждый день или один раз в неделю, это критически важное приложение, от него зависит бизнес и вот вдруг оно не уложилось во временные рамки, есть риск потерять деньги, а все из-за того что jpa построил запрос, на который ты не рассчитывал. Это не означает что jpa не нужен, просто есть случаи, когда от него больше проблем.

[bay73]

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

[Xobotun]

Незаслуженно неупомянут любимый мной jooq. Позволяет писать типизированные sql-запросы без неявных преобразований и с поддержкой конкретных фич баз данных, например, постгреса.

Но да, простые апдейты и селекты приходится делать руками. Зато поддержка cte, exists и какого-нибудь array_unnest позволяет писать эффективные запросы, имхо.

[gsaw]

На первой картинке персонаж по имени Data, актер уже в годах, потому old Data. Игра слов. Если бы не перевели, было бы понятнее :)

[souls_arch]

В комбо вся сила. Шутка. Никто не мешает парраллельно с jpa писать @query, открывать сессии фабрик и прочая-прочая, ежели возникнет необходимость. Зато у jpa 100% совместимость с любыми sql бд. А у индивид запросов - болт на рыло. Если ошибаюсь - поправьте. Конфиги так и так править при переключении, а смена дб на проекте вещь очень редкая. Проблем от jpa, кстати, хватает. Но они решаются.

[aleksandy]

Зато у jpa 100% совместимость с любыми sql бд

Смешно.

Проблем от jpa, кстати, хватает. Но они решаются.

Самая главная проблема JPA в том, что мало кто умеет и хочет в нём разбираться. А ещё многие простые вещи сделать через JPA можно только через такие дебри, что, порой, опуститься до уровня jdbc не кажется плохой идеей.

[easyJet]

Согласен, особенно если речь идет о high load и 150 абстракций над JDBC дороже также в плане оверхеда, чем просто воспользоваться JDBC template и написать чуть больше кода. Hibernate не плох сам по себе, но его грамотное применение и тюнинг производительности требует довольно высокого уровня экспертизы, что далеко не у каждого миддла встретишь.

[agoncharov]

Но с SQL-запросами, генерируемыми через JPA, вы не сможете этого сделать

Смогу, совершенно ничто не мешает

[patex]

Мне почему то ничто не мешает написать оптимизированный SQL запрос в том же Spring Jpa, но таких запросов 2-3 на весь проект, и несколько десятков простые запросов но к разным сущностям к которым я не хочу писать select/insert/update.

Просто используйте подходящий инструмент, если у вас много больших и сложных запросов  JPA не ваш выбор.

[gressmc]

Сравнивать jpa и jdbc в принципе подход такой себе. Не очень умный.

[Valerdos_UA]

Это не про везение. Те же люди сейчас не анализируют sql, генерируемый Hibernate, полагаю.

[easyJet]

На одном из проектов было правило, в чеклисте перед MR, обязательно в тестах прописывать ассерт на количество сгенерированных hibernate SQL запросов и как мне кажется это хорошая практика приучать к порядку разрабов, следить за количеством запросов, как минимум чтобы N+1 не прощёлкать.