Size: a a a

pgsql – PostgreSQL

2021 January 18

D

Dmitriy in pgsql – PostgreSQL
Centnot
Юзает, с вызовом процедур/функций в самой СУБД)
Эм, и нафига Hybernate тогда?
источник

D

Dmitriy in pgsql – PostgreSQL
Centnot
Смотря какой запрос он в итоге строит, если на 10к строк (я и такое видел), его потом долго и дорого в чувство приводить.
Не понимаю, как можно вызовами .where(..).andWhere(...).leftJoin(...) получить в итоге запрос на 10к строк. Фантастика, в жизни такого не видел. Приведите пример, пожалуйста
источник

am

a m in pgsql – PostgreSQL
Dmitriy
Не понимаю проблемы юзать только квери-билдер, как я уже выше писал. Это вообще никак на производительности не отразится
Проблема в том, что в процессе написании какого-нибудь простенького подзапроса при помощи всемогущего квери-билдера ты начинаешь бегать по комнате с криками.
источник

C

Centnot in pgsql – PostgreSQL
Dmitriy
Эм, и нафига Hybernate тогда?
Объектная модель - сериализация/десериализация кортежей из БД в экземпляры классов. У них же функций абсолютно разные. БД данные молотит, а ОРМ с классами восприятие объектов проще делает - наследование, инкапсуляция вот это все.
источник

D

Dmitriy in pgsql – PostgreSQL
a m
Проблема в том, что в процессе написании какого-нибудь простенького подзапроса при помощи всемогущего квери-билдера ты начинаешь бегать по комнате с криками.
Ну тут бывают трудности, да. Но и квери-билдеры бывают достаточно гибкие. В том числе и имеющие возможность кусок руками написать
источник

Ð

Ð in pgsql – PostgreSQL
Dmitriy
Не понимаю, как можно вызовами .where(..).andWhere(...).leftJoin(...) получить в итоге запрос на 10к строк. Фантастика, в жизни такого не видел. Приведите пример, пожалуйста
не понимаю, зачем использовать такую обертку, когда можно просто писать код на скл, чистый, понятный и со всеми возможностями субд, легко дополняемыми в новых версиях субд, да еще и с библиотеками и расширениями этой субд, о которых создатель билдера даже не подозревал
источник

SB

S B in pgsql – PostgreSQL
вы лучше объясните чем .leftjoin() лучше left join
источник

am

a m in pgsql – PostgreSQL
Dmitriy
Ну тут бывают трудности, да. Но и квери-билдеры бывают достаточно гибкие. В том числе и имеющие возможность кусок руками написать
В языках с поддержкой алгебраических типов можно писать чуть ли не удобнее чистого SQL’я, да с проверками на этапе компиляции. Но на этих языках никто не пишет, а существующие квери-билдеры — это смех сквозь слезы.
источник

C

Centnot in pgsql – PostgreSQL
Dmitriy
Не понимаю, как можно вызовами .where(..).andWhere(...).leftJoin(...) получить в итоге запрос на 10к строк. Фантастика, в жизни такого не видел. Приведите пример, пожалуйста
Был опыт с билдером на Entity Framework, вот сущностей 5 по join взять, и он только влёт начнёт такие выдавать. Это на БД где >250 таблиц
источник

D

Dmitriy in pgsql – PostgreSQL
Ð
не понимаю, зачем использовать такую обертку, когда можно просто писать код на скл, чистый, понятный и со всеми возможностями субд, легко дополняемыми в новых версиях субд, да еще и с библиотеками и расширениями этой субд, о которых создатель билдера даже не подозревал
Тем, что эта обёртка позволяет эти методы вызывать в условиях. Это гораздо проще поддерживать, чем if (name != null) { sql += " and where name= $' + str(i); i++;} - ну, вы поняли
источник

SB

S B in pgsql – PostgreSQL
а вы так не делайте, напишите 20 запросов отдельно :-)
источник

Ð

Ð in pgsql – PostgreSQL
a m
В языках с поддержкой алгебраических типов можно писать чуть ли не удобнее чистого SQL’я, да с проверками на этапе компиляции. Но на этих языках никто не пишет, а существующие квери-билдеры — это смех сквозь слезы.
говорят, в постгресе можно писать хранимки даже на яваскоипте ;)
источник

am

a m in pgsql – PostgreSQL
Dmitriy
Тем, что эта обёртка позволяет эти методы вызывать в условиях. Это гораздо проще поддерживать, чем if (name != null) { sql += " and where name= $' + str(i); i++;} - ну, вы поняли
Не поняли. В ORM’ах точно такую же задачу решают волшебные гномики, по-вашему, которые эту простыню за вас пишут?
Все делается красивее. Получается некий хеш с параметрами, по нему проходимся циклом и собираем SQL. Все.
источник

Ð

Ð in pgsql – PostgreSQL
Dmitriy
Тем, что эта обёртка позволяет эти методы вызывать в условиях. Это гораздо проще поддерживать, чем if (name != null) { sql += " and where name= $' + str(i); i++;} - ну, вы поняли
у вас весьма странные представления об условиях в plpgsql
источник

D

Dmitriy in pgsql – PostgreSQL
a m
Не поняли. В ORM’ах точно такую же задачу решают волшебные гномики, по-вашему, которые эту простыню за вас пишут?
Все делается красивее. Получается некий хеш с параметрами, по нему проходимся циклом и собираем SQL. Все.
В ORM, кроме построения запроса и маппера, есть ещё куча магии в виде LAZY LOADING и прочих плюшек, которые как раз адовые запросы и генерят
источник

am

a m in pgsql – PostgreSQL
Напугали, блин, программистов тем, что чего-то там «много». Раз много, тогда решает более общую задачу. Все.
источник

am

a m in pgsql – PostgreSQL
Dmitriy
В ORM, кроме построения запроса и маппера, есть ещё куча магии в виде LAZY LOADING и прочих плюшек, которые как раз адовые запросы и генерят
Потому что у ORM есть нелегкая задача угадать, чего хочет быдлокодер. Когда тебе надо список параметров в запрос перевести — такой задачи нет. Собираешь SQL и идешь спать.
источник

D

Dmitriy in pgsql – PostgreSQL
Окей, убедили. Покажите мне нормальное построение SQL-запроса с условиями в коде. На любом языке программирования, но не на хранимке. Не на хранимке, потому что их использование для таких задач у многих разработчиков (не только у меня) вызывает множество споров.
источник

D

Dmitriy in pgsql – PostgreSQL
Я хочу увидеть, как в коде можно читабельно построить SQL-запрос с условиями
источник

D

Devid QA in pgsql – PostgreSQL
никак
источник