Странно сравнивать с JPA, фактически, не использовав в примере JPA) Ведь основная сила и предназначение JPA - это "автогенерация" запросов к БД из наименований методов в репозитории. Когда в JPA-шных репозиториях появляются аннотации Query, то это уже не "true JPA") Еще Вы, уважаемый автор, не рассказали, что отказавшись от Spring Data и Spring JPA, косвенно отказались и от Hibernate - следовательно, нужно самим позаботиться о поддержке транзакционности, кэшировании и других "полезностях". На мой взгляд, нужно сначала попытаться выжать максимум из Spring Data JPA, а уж потом, полностью осознав что именно связка "хибер-дата-жпа" является "бутылочным горлышком" (по перформансу, нагрузке на СУБД, потребляемым ресурсам), только тогда перейти на JooQ)
Комментарий отличный, спасибо вам большое за обратную связь. Я не совсем хотел делать это в жесткое противопоставление, потому что явно известно, что JPA пользоваться зачастую удобнее, не хотел задеть ни чьих чувств, как говорится 😅😇
очень сомнительное преимущество когда в одном запросе whereIn/Exists/subselect а в другом join. Все СУБД которые не MYSQL имеют планировщик запроса, который используя внутреннию статистику отлично математически перелопатит твой запрос в нечто оптимизированное. Вам в любой книжке по любой СУБД скажут, что думать нужно про читаемость и выразительность запроса, а не про сравнение join/subselect. Я лично вижу для себя другой аспект. Появляется какой то kotlin-style при работе с sql
Полезно, толково, понятно, без воды, приятный голос лектора. Спасибо огромное
Благодарю за обратную связь ❤️
Привет, спасибо за то что продолажешь свое дело! Я студент-програмист и твои видео очень помогают мне!
Твои ролики сильно помогают в обучении, спасибо огромное
Спасибо вам за обратную связь!
Для маппинга в DTO-шки используй MapStruct. Еще Lombok советую изучить)
Спасибо:)
Очень полезно!
Стараюсь😌
Спасибо за интересный рассказ! А как генерировать классы в gradle?
Здравствуйте, извините за поздний ответ, в gradle этого не делал, но принцип, в теории, тот же, нужен плагин и зависимость.
Чем лучше QueryDsl ?
Не знаю, что лучше, а что практичнее. Может сделаю сравнение в будущем.
От QueryDSL он еще больше "просвятится"))) Там можно ее подружить с Spring Data вместо JPA)
Странно сравнивать с JPA, фактически, не использовав в примере JPA) Ведь основная сила и предназначение JPA - это "автогенерация" запросов к БД из наименований методов в репозитории. Когда в JPA-шных репозиториях появляются аннотации Query, то это уже не "true JPA") Еще Вы, уважаемый автор, не рассказали, что отказавшись от Spring Data и Spring JPA, косвенно отказались и от Hibernate - следовательно, нужно самим позаботиться о поддержке транзакционности, кэшировании и других "полезностях". На мой взгляд, нужно сначала попытаться выжать максимум из Spring Data JPA, а уж потом, полностью осознав что именно связка "хибер-дата-жпа" является "бутылочным горлышком" (по перформансу, нагрузке на СУБД, потребляемым ресурсам), только тогда перейти на JooQ)
Комментарий отличный, спасибо вам большое за обратную связь.
Я не совсем хотел делать это в жесткое противопоставление, потому что явно известно, что JPA пользоваться зачастую удобнее, не хотел задеть ни чьих чувств, как говорится 😅😇
@NerzonIT , вот то, что Вы в ответ написали, нужно было в видео сказать и все)) А в целом, у Вас хорошо получается доносить информацию)
очень сомнительное преимущество когда в одном запросе whereIn/Exists/subselect а в другом join. Все СУБД которые не MYSQL имеют планировщик запроса, который используя внутреннию статистику отлично математически перелопатит твой запрос в нечто оптимизированное. Вам в любой книжке по любой СУБД скажут, что думать нужно про читаемость и выразительность запроса, а не про сравнение join/subselect.
Я лично вижу для себя другой аспект. Появляется какой то kotlin-style при работе с sql