Привет!

Для меня работа с БД - это самая большая боль Эргономичного подхода.
Возможно, после публикации второго тома ретро (ориентировачно в четверг) - я напишу пост о том, почему мне не подходит хибер и почему подходит Spring Data JDBC.

Но SDJ хоть и подходит концептуально, в повседневной жизни бывает довольно болючь (о чём я тоже когда-нибудь напишу).

Поэтому я, стараясь не привлекать внимание санитаров, подумываю о собственном ОРМе (у меня уже даже есть небольшой прототип АПИ, работающий поверх Мап).

И в ОРМе самой большой проблемой видится загрузка развесистых агрегатов - агрегатов с несколькими вложенными коллекциями. И если оставаться в широко поддерживаемом подмножестве SQL, то у этой задачи (как казалось) нет эффективного решения - либо куча отдельных запросов, либо декартово произведение. Либо какой-то умный планировщик, который комбинирует эти подходы, и на котором если не докторскую, то кандидатскую точно можно защитить.

В качестве потенциально решения этой проблемы на "продвинутом SQL" мне виделся SQL MULTISET или его эмуляция на json-е.

А сегодня наткнулся на статью с амбициозным названием "This is the Beginning of the End of the N+1 Problem" от основного разработчика SDJ, где он описывает решение на оконных функциях. И самое чудесное, что это решение в минимальном виде уже работает в мейлстоуне SDJ 3.2.0.

Возможно, мне всё-таки не придётся писать ОРМ и SDJ станет тем инструментом работы с БД, который не только подходит мне идеологически, но и зубную боль не вызывает.

P.S.
Но не спешите переезжать на SDJ ради решения проблемы Н+1. Если вы сейчас на хибере, то у вас совершенно точно изменяемая модель данных и, скорее всего, не функциональная архитектура. И если вы не смените подход к проектированию на неизменяемую модель данных и функциональную архитектуру, то получите все те ужасы, баги и боли, которых говорит Андрей в Меняем Spring Data JPA на Spring Data JDBC!. И очень мало получите взамен.

#posts@ergonomic_code #spring_data_jdbc@ergonomic_code #ergo_approach@ergonomic_code