D
Юзает, с вызовом процедур/функций в самой СУБД)
Эм, и нафига Hybernate тогда?
Size: a a a
2021 January 18
D
Смотря какой запрос он в итоге строит, если на 10к строк (я и такое видел), его потом долго и дорого в чувство приводить.
Не понимаю, как можно вызовами .where(..).andWhere(...).leftJoin(...) получить в итоге запрос на 10к строк. Фантастика, в жизни такого не видел. Приведите пример, пожалуйста
am
Не понимаю проблемы юзать только квери-билдер, как я уже выше писал. Это вообще никак на производительности не отразится
Проблема в том, что в процессе написании какого-нибудь простенького подзапроса при помощи всемогущего квери-билдера ты начинаешь бегать по комнате с криками.
C
Эм, и нафига Hybernate тогда?
Объектная модель - сериализация/десериализация кортежей из БД в экземпляры классов. У них же функций абсолютно разные. БД данные молотит, а ОРМ с классами восприятие объектов проще делает - наследование, инкапсуляция вот это все.
D
Проблема в том, что в процессе написании какого-нибудь простенького подзапроса при помощи всемогущего квери-билдера ты начинаешь бегать по комнате с криками.
Ну тут бывают трудности, да. Но и квери-билдеры бывают достаточно гибкие. В том числе и имеющие возможность кусок руками написать
Ð
Не понимаю, как можно вызовами .where(..).andWhere(...).leftJoin(...) получить в итоге запрос на 10к строк. Фантастика, в жизни такого не видел. Приведите пример, пожалуйста
не понимаю, зачем использовать такую обертку, когда можно просто писать код на скл, чистый, понятный и со всеми возможностями субд, легко дополняемыми в новых версиях субд, да еще и с библиотеками и расширениями этой субд, о которых создатель билдера даже не подозревал
SB
вы лучше объясните чем .leftjoin() лучше left join
am
Ну тут бывают трудности, да. Но и квери-билдеры бывают достаточно гибкие. В том числе и имеющие возможность кусок руками написать
В языках с поддержкой алгебраических типов можно писать чуть ли не удобнее чистого SQL’я, да с проверками на этапе компиляции. Но на этих языках никто не пишет, а существующие квери-билдеры — это смех сквозь слезы.
C
Не понимаю, как можно вызовами .where(..).andWhere(...).leftJoin(...) получить в итоге запрос на 10к строк. Фантастика, в жизни такого не видел. Приведите пример, пожалуйста
Был опыт с билдером на Entity Framework, вот сущностей 5 по join взять, и он только влёт начнёт такие выдавать. Это на БД где >250 таблиц
D
Ð
не понимаю, зачем использовать такую обертку, когда можно просто писать код на скл, чистый, понятный и со всеми возможностями субд, легко дополняемыми в новых версиях субд, да еще и с библиотеками и расширениями этой субд, о которых создатель билдера даже не подозревал
Тем, что эта обёртка позволяет эти методы вызывать в условиях. Это гораздо проще поддерживать, чем
if (name != null) { sql += " and where name= $' + str(i); i++;} - ну, вы понялиSB
а вы так не делайте, напишите 20 запросов отдельно :-)
Ð
В языках с поддержкой алгебраических типов можно писать чуть ли не удобнее чистого SQL’я, да с проверками на этапе компиляции. Но на этих языках никто не пишет, а существующие квери-билдеры — это смех сквозь слезы.
говорят, в постгресе можно писать хранимки даже на яваскоипте ;)
am
Тем, что эта обёртка позволяет эти методы вызывать в условиях. Это гораздо проще поддерживать, чем
if (name != null) { sql += " and where name= $' + str(i); i++;} - ну, вы понялиНе поняли. В ORM’ах точно такую же задачу решают волшебные гномики, по-вашему, которые эту простыню за вас пишут?
Все делается красивее. Получается некий хеш с параметрами, по нему проходимся циклом и собираем SQL. Все.
Все делается красивее. Получается некий хеш с параметрами, по нему проходимся циклом и собираем SQL. Все.
Ð
Тем, что эта обёртка позволяет эти методы вызывать в условиях. Это гораздо проще поддерживать, чем
if (name != null) { sql += " and where name= $' + str(i); i++;} - ну, вы понялиу вас весьма странные представления об условиях в plpgsql
D
Не поняли. В ORM’ах точно такую же задачу решают волшебные гномики, по-вашему, которые эту простыню за вас пишут?
Все делается красивее. Получается некий хеш с параметрами, по нему проходимся циклом и собираем SQL. Все.
Все делается красивее. Получается некий хеш с параметрами, по нему проходимся циклом и собираем SQL. Все.
В ORM, кроме построения запроса и маппера, есть ещё куча магии в виде LAZY LOADING и прочих плюшек, которые как раз адовые запросы и генерят
am
Напугали, блин, программистов тем, что чего-то там «много». Раз много, тогда решает более общую задачу. Все.
am
В ORM, кроме построения запроса и маппера, есть ещё куча магии в виде LAZY LOADING и прочих плюшек, которые как раз адовые запросы и генерят
Потому что у ORM есть нелегкая задача угадать, чего хочет быдлокодер. Когда тебе надо список параметров в запрос перевести — такой задачи нет. Собираешь SQL и идешь спать.
D
Окей, убедили. Покажите мне нормальное построение SQL-запроса с условиями в коде. На любом языке программирования, но не на хранимке. Не на хранимке, потому что их использование для таких задач у многих разработчиков (не только у меня) вызывает множество споров.
D
Я хочу увидеть, как в коде можно читабельно построить SQL-запрос с условиями
D
никак