Хотелоь бы подискутировать, провалидировать мысли.
Имхо ORM в целом работают плохо. В веб-приложениях, интенсивно работающих с базой, часть бизнес-логики (условия, джойны, группировки) неизбежно встроена в SQL-запросы (а не только существует в коде приложения), поэтому в случае ORM происходит автогенерация сложных SQL, которая по любому работает через жопу, неоптимально, да еще и плохо дебажится. DBAшники не менее чем в 50% своих выступлений упомянают примеры SQL, порожденных ORM-ками (там обычно зло ацкой сотоны из чорного ада).
Это конечно дело вкуса, но из моего опыта мне всегда было проще выразить запрос в сыром виде, а потом уже накручивать логику на результат, чем всё делать сразу через хитроописанную взаимосвязь сущностей. Ну а для сложных отчетов, понятно, ORM - это просто ппц.
С другой стороны, query builderы (не ORM, а просто построители запросов) часто помогают в случае, когда есть форма с миллионом необязательных галочек и инпутов, и строить сырой запрос конкатенацией - можно тронуться умом и допустить секьюрити проблемы.
Поэтому лично я для себя пришел к такому выводу: везде стоит писать сырые запросы, кроме тех случаев, когда надо запрос собирать из частей. Но и в этом случае использвать условный Squirrel (query builder для Go), а не условный Gorm (ORM для Go). Да, писанины немного больше, но код становится при этом более понятный и поддерживаемый.
В мире Go вообще не оч принято использовать ORM, фреймворки и т.д., пара лишних строк кода - это всего лишь хорошее медитативное занятие (c)
Имхо ORM в целом работают плохо. В веб-приложениях, интенсивно работающих с базой, часть бизнес-логики (условия, джойны, группировки) неизбежно встроена в SQL-запросы (а не только существует в коде приложения), поэтому в случае ORM происходит автогенерация сложных SQL, которая по любому работает через жопу, неоптимально, да еще и плохо дебажится. DBAшники не менее чем в 50% своих выступлений упомянают примеры SQL, порожденных ORM-ками (там обычно зло ацкой сотоны из чорного ада).
Это конечно дело вкуса, но из моего опыта мне всегда было проще выразить запрос в сыром виде, а потом уже накручивать логику на результат, чем всё делать сразу через хитроописанную взаимосвязь сущностей. Ну а для сложных отчетов, понятно, ORM - это просто ппц.
С другой стороны, query builderы (не ORM, а просто построители запросов) часто помогают в случае, когда есть форма с миллионом необязательных галочек и инпутов, и строить сырой запрос конкатенацией - можно тронуться умом и допустить секьюрити проблемы.
Поэтому лично я для себя пришел к такому выводу: везде стоит писать сырые запросы, кроме тех случаев, когда надо запрос собирать из частей. Но и в этом случае использвать условный Squirrel (query builder для Go), а не условный Gorm (ORM для Go). Да, писанины немного больше, но код становится при этом более понятный и поддерживаемый.
В мире Go вообще не оч принято использовать ORM, фреймворки и т.д., пара лишних строк кода - это всего лишь хорошее медитативное занятие (c)