#spring_data_jdbc — Public Fediverse posts

Оптимизация запросов в Spring Data JDBC

Я думаю многие согласятся, что Spring Data JDBC — это ORM, который занимает конкретную нишу: он предоставляет более легковесный репозиторный слой доступа к данным поверх реляционной БД без persistence context, без lazy loading, без dirty checking и т.д. Иными словами, Spring Data JDBC реализует принцип "what you see is what you get" — каждое обращение к репозиторию означает конкретный SQL-запрос в БД, который просто достаёт дерево Aggregate. Это и преимущество, и, тем не менее, иногда это источник потенциальных проблем с производительностью. В этой статье я разберу ключевые подходы к оптимизации запросов в Spring Data JDBC: от дизайна агрегатов и Single Query Loading, до Stream в качестве возвращаемого значения и @Modifying запросов. Разберём всё с кодом и на примерах. Только один момент - в этой статье я не затрагиваю Spring Data открытые/закрытые Projection-ы и т.п, так как я предполагаю, что пользователи Spring Data знают, что это и в каких ситуациях их стоит использовать. Эти вещи не специфичны для Spring Data JDBC, я же буду говорить про вещи более специфичные для Spring Data JDBC .

https://habr.com/ru/companies/spring_aio/articles/1010558/

#java #spring #spring_data #spring_data_jdbc #orm #sql #performance

Оптимизация запросов в Spring Data JDBC

Я думаю многие согласятся, что Spring Data JDBC — это ORM, который занимает конкретную нишу: он предоставляет более легковесный репозиторный слой доступа к данным поверх реляционной БД без persistence context, без lazy loading, без dirty checking и т.д. Иными словами, Spring Data JDBC реализует принцип "what you see is what you get" — каждое обращение к репозиторию означает конкретный SQL-запрос в БД, который просто достаёт дерево Aggregate. Это и преимущество, и, тем не менее, иногда это источник потенциальных проблем с производительностью. В этой статье я разберу ключевые подходы к оптимизации запросов в Spring Data JDBC: от дизайна агрегатов и Single Query Loading, до Stream в качестве возвращаемого значения и @Modifying запросов. Разберём всё с кодом и на примерах. Только один момент - в этой статье я не затрагиваю Spring Data открытые/закрытые Projection-ы и т.п, так как я предполагаю, что пользователи Spring Data знают, что это и в каких ситуациях их стоит использовать. Эти вещи не специфичны для Spring Data JDBC, я же буду говорить про вещи более специфичные для Spring Data JDBC .

https://habr.com/ru/companies/spring_aio/articles/1010558/

#java #spring #spring_data #spring_data_jdbc #orm #sql #performance

Оптимизация запросов в Spring Data JDBC

Я думаю многие согласятся, что Spring Data JDBC — это ORM, который занимает конкретную нишу: он предоставляет более легковесный репозиторный слой доступа к данным поверх реляционной БД без persistence context, без lazy loading, без dirty checking и т.д. Иными словами, Spring Data JDBC реализует принцип "what you see is what you get" — каждое обращение к репозиторию означает конкретный SQL-запрос в БД, который просто достаёт дерево Aggregate. Это и преимущество, и, тем не менее, иногда это источник потенциальных проблем с производительностью. В этой статье я разберу ключевые подходы к оптимизации запросов в Spring Data JDBC: от дизайна агрегатов и Single Query Loading, до Stream в качестве возвращаемого значения и @Modifying запросов. Разберём всё с кодом и на примерах. Только один момент - в этой статье я не затрагиваю Spring Data открытые/закрытые Projection-ы и т.п, так как я предполагаю, что пользователи Spring Data знают, что это и в каких ситуациях их стоит использовать. Эти вещи не специфичны для Spring Data JDBC, я же буду говорить про вещи более специфичные для Spring Data JDBC .

https://habr.com/ru/companies/spring_aio/articles/1010558/

#java #spring #spring_data #spring_data_jdbc #orm #sql #performance

Оптимизация запросов в Spring Data JDBC

Я думаю многие согласятся, что Spring Data JDBC — это ORM, который занимает конкретную нишу: он предоставляет более легковесный репозиторный слой доступа к данным поверх реляционной БД без persistence context, без lazy loading, без dirty checking и т.д. Иными словами, Spring Data JDBC реализует принцип "what you see is what you get" — каждое обращение к репозиторию означает конкретный SQL-запрос в БД, который просто достаёт дерево Aggregate. Это и преимущество, и, тем не менее, иногда это источник потенциальных проблем с производительностью. В этой статье я разберу ключевые подходы к оптимизации запросов в Spring Data JDBC: от дизайна агрегатов и Single Query Loading, до Stream в качестве возвращаемого значения и @Modifying запросов. Разберём всё с кодом и на примерах. Только один момент - в этой статье я не затрагиваю Spring Data открытые/закрытые Projection-ы и т.п, так как я предполагаю, что пользователи Spring Data знают, что это и в каких ситуациях их стоит использовать. Эти вещи не специфичны для Spring Data JDBC, я же буду говорить про вещи более специфичные для Spring Data JDBC .

https://habr.com/ru/companies/spring_aio/articles/1010558/

#java #spring #spring_data #spring_data_jdbc #orm #sql #performance

Поддержка Spring 7, Reactive Debugger, работа с БД и HTTP прямо в IDE: это и много другое в Amplicode 2025.2

Amplicode 2025.2 — это релиз, в котором мы закрыли десятки мелких раздражающих моментов, и усилили поддержку ключевых технологий — от Spring и Spring Data JDBC до Docker, Kubernetes и Terraform. А также сделали интеграцию с базами и HTTP-сервисами ещё более бесшовной.

https://habr.com/ru/companies/haulmont/articles/941604/

#spring #spring_data_jdbc #terraform #docker #docker_compose #kubernetes #java #http #dbeaver #intellij