наверное речь про небольшой оверхэд в гошном коде

А кто-нибудь знает как без орм просто достать сущность + связь (например один ко многим) и сделать слайс из связанных сущностей?

Я знаю. Хотя сейчас тут за ORM топлю ) Простым джойном

Какие именно? О чем речь?

ну, тебе как минимум надо переводить твой код в SQL

А что за оверхэд?

Цепочка вызовов функций больше думаю это и есть оверхед

речь про неоптимально составленные запросы. в случае обыччного круда орм работает, как только что-то сложное пошло - орм плывет и все сводится обратно к билдеру или самописным кастом запросам. которые, впрочем, могут жить рядом с орм.

Я знаю. Хотя сейчас тут за ORM топлю ) Простым джойном

нет, простой джойн даёт простой джойн и результат там плоская таблица (как и практически любой результат в sql), а потом предлагается руками это ещё распихивать по родитель - слайс детей что orm (ну по крайней мере gorm) может легко делать автоматически

речь про неоптимально составленные запросы. в случае обыччного круда орм работает, как только что-то сложное пошло - орм плывет и все сводится обратно к билдеру или самописным кастом запросам. которые, впрочем, могут жить рядом с орм.

ORM не плывет. Просто сложные запросы в нем мало кто умеет делать, на SQL сильно проще

Если таких кейсов не очень много, то можно юзать sql builder. Это гораздо православнее ORM

верно

речь про неоптимально составленные запросы. в случае обыччного круда орм работает, как только что-то сложное пошло - орм плывет и все сводится обратно к билдеру или самописным кастом запросам. которые, впрочем, могут жить рядом с орм.

1. тот же gorm и так можно считать своего рода query builder, там частенько всё к кускам обычного sql сводится 2. можно всякие простые круды делать через орм, а что-то особо забористое делать на сыром sql (через орм опять же, но орм тут особой работы не делает)

ORM не плывет. Просто сложные запросы в нем мало кто умеет делать, на SQL сильно проще

еще орм далек от sql, и муторно тестить как орм построит запрос.. вот вот столкнулся с этой проблемой на проекте с орм

и тебе не всегда нужна цельная сущность, как сущность. кроме апдейта и инсерта

разве что, тесты писать удобно с орм и то сомнительно

В защиту ORM приведу такой кейс. На странице магазина фильтр по разным характеристикам товаров, коих десятки, все поля опциональные. Как такое на бэке обрабатывать без ORM? Как такой SQL составить? Склеивать строчки в where ... and ... and ...? Это очень error-prone

Это вообще не задача ОРМ. Если у тебя сложные фильтры, то пишется DSL. Хороший пример это JQL у Jira.

кто-то в 2025 еще хейтит орм ?

Все

Много кто ) Но, Я так и не понял, почему оно медленнее чем SQL. Не больший контроль, не ещё что-то, а про скорость сразу говорят. Как будто ORM из всех вариантов самый неоптимальный SQL генерит

Есть куча причин почему оно медленнее. Попробуй реализовать одну задачу на ORM и SQL, проведи нагрузочное тестирование, будешь удивлен.

А кто-нибудь знает как без орм просто достать сущность + связь (например один ко многим) и сделать слайс из связанных сущностей?

Задача на джуна. Это обычная рабочая задача. Почему это должно быть проблемой?

Есть куча причин почему оно медленнее. Попробуй реализовать одну задачу на ORM и SQL, проведи нагрузочное тестирование, будешь удивлен.

Может ты озвучишь эти причины? А то правильно нагрузочно потестить именно что надо - целая наука

Задача на джуна. Это обычная рабочая задача. Почему это должно быть проблемой?

Потому что это не должно быть задачей в принципе. Джуны не должны её решать. Потому что она легко решается орм.

А что за оверхэд?

Язык в рантайск должен тратить ресурсы на диспетчеризацию запросов как минимум.

Может ты озвучишь эти причины? А то правильно нагрузочно потестить именно что надо - целая наука

например ряд ормок когда подгружают релейшены делают это отдельным селектом, а не джоином

Цепочка вызовов функций больше думаю это и есть оверхед

Учитывая что цепочка может быть очень длинной) меньшую часть из них пишет разработчик сам.

на большом количестве строк дает ощутимую просадку

ну и в целом более сложные запросы не всегда оптимально составляются внутри ормки

На го не замерял, но в питоне задача решенная на алхимии более чем в 5 раз медленнее, чем простой SQL через asyncpg

ну тут дело даже не в секундах на конкретную задачу

ну и в целом более сложные запросы не всегда оптимально составляются внутри ормки

Более сложные задачи не всегда оптимально решаются на go разработчиками из мяса )

а в том что внутри эксплейна возвращается

Более сложные задачи не всегда оптимально решаются на go разработчиками из мяса )

согласен, но в случае сырого sql у тебя хотя бы есть шанс написать оптимально, ормки часто такого шанса не дают вообще

#резюме #parttime Занятость: частичная (20 часов в неделю). Senior Golang Developer (более 5 лет опыта) Ставка: 3000 рублей/час. Контакты - @emplonics. Привет. Ищу частичную занятость на проект любой сложности. Мои достижения как golang разработчика: - Участвовал в разработке собственного S3 хранилища. - Потоковая обработка видео - транскодинг и т.д. для сервиса видеошеринга. - Внедрение распределенных транзакций в систему, состоящую из 20+ микросервисов. - По мелочи: внедрение метрик/трейсов в проект; работа с локальным кэшем для сокращения трафика сети; написание Lua-скриптов для redis (eval); написание продюсеров/консьюмеров для kafka и nats jetstream; написание автотестов; работа с buf/easyp.

Кого зарефать в бигтех пишите в лс, + подскажу что спрашивают, как проходит. (От мидл и выше)

Много кто ) Но, Я так и не понял, почему оно медленнее чем SQL. Не больший контроль, не ещё что-то, а про скорость сразу говорят. Как будто ORM из всех вариантов самый неоптимальный SQL генерит

Памяти много выделяется, на конвертацию в dto + рефлексия что скорость сильно снижает

А кто-нибудь знает как без орм просто достать сущность + связь (например один ко многим) и сделать слайс из связанных сущностей?

а как сложно?

а как сложно?

руками

тогда лучше не писать на го

тогда лучше не писать на го

почему?

А кто-нибудь знает как без орм просто достать сущность + связь (например один ко многим) и сделать слайс из связанных сущностей?

в реляционной бд нет понятия сущности. Есть таблицы и их отношения

в реляционной бд нет понятия сущности. Есть таблицы и их отношения

в реляционной бд нет, в приложении есть

в реляционной бд нет, в приложении есть

в этом и состоит ваша проблема

в этом и состоит ваша проблема

да, и object-relational mapping (сокращённо orm) её решает😁

ну или её решают программисты-пуристы которые не пользуются orm по религиозным соображениям

да, и object-relational mapping (сокращённо orm) её решает😁

а ещё её решает избавление от ооп-мышления

а ещё её решает избавление от ооп-мышления

не решает

потому что апишка (и клиенты юзающие эту апишку) примерно всегда хочет структурированное апи с вложенными сущностями, а не плоскими таблицами

потому что апишка (и клиенты юзающие эту апишку) примерно всегда хочет структурированное апи с вложенными сущностями, а не плоскими таблицами

ваш изначальный вопрос решается одним JOIN

ваш изначальный вопрос решается одним JOIN

на уровне бд - да, на уровне приложения - этого недостаточно

на уровне бд - да, на уровне приложения - этого недостаточно

я ответил на ваш вопрос. Если вы хотели узнать что-то иное, то нужно было задать другой вопрос

на уровне приложения нужно будет 2 структуры создать и db.Query() написать

на уровне приложения нужно будет 2 структуры создать и db.Query() написать

на уровне приложения надо будет получить из бд плоские данные + руками их "структуризировать" распихав по структурам и вложенным в них слайсам других структур ну или заюзать орм которая сделать такое же, но автоматически

вот и вопрос есть ли такая штука которая без орм может это автоматически сделать

на уровне приложения надо будет получить из бд плоские данные + руками их "структуризировать" распихав по структурам и вложенным в них слайсам других структур ну или заюзать орм которая сделать такое же, но автоматически

да, видите как просто

вот и вопрос есть ли такая штука которая без орм может это автоматически сделать

Тут только 2 варианта, вы его сами разрулите или за вас его орм разрулит. Любая система которая решает вашу проблему, имхо будет орм

хорошо спасибо, тогда смысла отказываться от орм особого нет

на уровне приложения надо будет получить из бд плоские данные + руками их "структуризировать" распихав по структурам и вложенным в них слайсам других структур ну или заюзать орм которая сделать такое же, но автоматически

блин) друг, SQL может все и даже больше, чем делает орм) как можно говорить что проблема не решается, если орм генерирует в итоге тот же SQL)) в чем проблема сразу написать нужный запрос вместо орм?)

блин) друг, SQL может все и даже больше, чем делает орм) как можно говорить что проблема не решается, если орм генерирует в итоге тот же SQL)) в чем проблема сразу написать нужный запрос вместо орм?)

а зачем писать то, что можно не писать? зачем писать циклы наполнения из массивов пришешдших и раскладывать их туда сюда раз за разом? вам за время платят, это понятно, но вы когда-нибудь тратили свои деньги на разработку? написал модель, и все готово —весь набор типовых ситуций :)

а зачем писать то, что можно не писать? зачем писать циклы наполнения из массивов пришешдших и раскладывать их туда сюда раз за разом? вам за время платят, это понятно, но вы когда-нибудь тратили свои деньги на разработку? написал модель, и все готово —весь набор типовых ситуций :)

ты в курсе что ты можешь не писать циклы, а сразу получить данные нужной структуры с разным уровнем вложенности? Вопрос только в сложности запроса, как sql, так и орм

ты в курсе что ты можешь не писать циклы, а сразу получить данные нужной структуры с разным уровнем вложенности? Вопрос только в сложности запроса, как sql, так и орм

допустим, но зачем? если можно написать модель

Мне не платят за время) у меня свой продукт)

Мне не платят за время) у меня свой продукт)

тогда я удивлен

допустим, но зачем? если можно написать модель

Какой длины будет реальная цепочка вызовов? Сколько там будет рефлексии? Какой оверхед на диспетчеризацию методов ОРМ?

тогда я удивлен

ничего удивительного)))

Парни, а тут вакансии бывают?

еще орм далек от sql, и муторно тестить как орм построит запрос.. вот вот столкнулся с этой проблемой на проекте с орм

А, главное, непонятно зачем. Разумеется, если это не проект, где сущности описываются декларативно, типа GraphQL. Я кайфую от sqlc. Написал sql файл, запустил кодеген и репо-слой готов. Сказка!

Парни, а тут вакансии бывают?

Время кризисное, экономика падает, работы мало

Какой длины будет реальная цепочка вызовов? Сколько там будет рефлексии? Какой оверхед на диспетчеризацию методов ОРМ?

А вы что оптимизируете? Зачем, где просадка?

Какой длины будет реальная цепочка вызовов? Сколько там будет рефлексии? Какой оверхед на диспетчеризацию методов ОРМ?

Какая разница, если в приложении есть сетевые запросы?

Какой длины будет реальная цепочка вызовов? Сколько там будет рефлексии? Какой оверхед на диспетчеризацию методов ОРМ?

Скорее всего мизерный

Скорее всего мизерный

Попробуй и проведи нагрузочное) хотя бы каким-нибудь wrk самое простое) будет интересно всем посмотреть на результаты

Какая разница, если в приложении есть сетевые запросы?

Как этот вопрос матчится с моим предыдущим тейком?)

Попробуй и проведи нагрузочное) хотя бы каким-нибудь wrk самое простое) будет интересно всем посмотреть на результаты

зачем?

зачем?

потому-что ты говоришь "скорее всего", что подразумевает под собой набор догадок, а не реальных метрик) ну и просто всем интересно будет думаю

блин) друг, SQL может все и даже больше, чем делает орм) как можно говорить что проблема не решается, если орм генерирует в итоге тот же SQL)) в чем проблема сразу написать нужный запрос вместо орм?)

ну и зачем вообще тогда го, если sql может всё? давайте тогда бэк на чистом sql делать😁

потому-что ты говоришь "скорее всего", что подразумевает под собой набор догадок, а не реальных метрик) ну и просто всем интересно будет думаю

ну я не замечал такого страшного оверхеда от горм и не пытаюсь сделать всё на sql

Везде баланс важен, чего передёргивать. Часто удобен ORM, при этом иногда запрос хитровыебанный, который не часто встречается, ну его и сделайте в SQL

Везде баланс важен, чего передёргивать. Часто удобен ORM, при этом иногда запрос хитровыебанный, который не часто встречается, ну его и сделайте в SQL

ну да

ну и зачем вообще тогда го, если sql может всё? давайте тогда бэк на чистом sql делать😁

а я тебе отвечу) выбор языка иногда зависит чисто от бизнесовых требований) например когда нужно поставлять клиентам приложение целиком и крутить на их машинах) как защитить свой код как интеллектуальную собственность тогда?)

этот тейк не имеет отношения к обсуждению орм, но хотел заметить что выбор языка это в последнюю очередь про скорость скорее всего)

блин) друг, SQL может все и даже больше, чем делает орм) как можно говорить что проблема не решается, если орм генерирует в итоге тот же SQL)) в чем проблема сразу написать нужный запрос вместо орм?)

я не огромный эксперт в области использования различных орм, но кажется что орм гарантириует экранирование и обеспечивает безопасность, что лучше, чем экранировать запросы вручную

ну я не замечал такого страшного оверхеда от горм и не пытаюсь сделать всё на sql

ну, а все остальные замечают) такими абстрактными ответами можно перекидываться сколько угодно))

я не огромный эксперт в области использования различных орм, но кажется что орм гарантириует экранирование и обеспечивает безопасность, что лучше, чем экранировать запросы вручную

я тебе скажу, что многие драйверы баз данных это тоже обеспечивают) нужно просто читать доку)

Какого-то рода компромисс - sqlc