Почему некоторые программисты на GO работают с бд на голом SQL без ORM?

Почему некоторые решают рабоатать с бд на чистом sql это дает больше возможностей или ?
  • Вопрос задан
  • 11038 просмотров
Решения вопроса 5
vabka
@vabka
Токсичный шарпист
Не гошник, но расскажу в целом.
1. На 1 уровень абстракции меньше. При работе с ORM нужно думать одновременно и об особенностях твоей ORM-ки и об особенностях базы.
2. На сыром SQL некоторые вещи сделать проще, чем с ORM-ками.
3. Лучше сырой SQL, чем тупая ORM-ка.
4. Некоторые ORM-ки могут негативно влиять на производительность.

Если тебе приходится при работе с ORM писать куски SQL-я (например для WHERE), передавать названия колонок в параметрах, и при этом ты не можешь использовать специфику твоей базы не опускаясь до уровня сырого SQL, то это плохая ORM.

Нормальная орм-ка должна упрощать код и при этом не увеличивать пространство для ошибок.
На сколько я знаю, Go не позволяет хорошую ORM-ку создать чисто из-за своего синтаксиса и системы типов.

Нормальные ормки я пока видел только:
1. В C# из-за Linq
2. В Rust из-за макросов.
Ответ написан
opium
@opium
Просто люблю качественно работать
А зачем когда ты сам можешь все контролировать
Тут два основных паттерна
1 когда запросов мало и они простые и ты понимаешь как они работают и никаких косяков со странными данными из вне прийти не должно или ты это уже сам экранироовал , реально намного быстрее напрямую сделать чем вникать в орм
2 когда тебе в каких то частях нужен перформанс или когда орм генерит еретические запросы там где у тебя сложная логика и приходится их переписывать напрямую
Ну и забыл третье вкусовщина
Ответ написан
Комментировать
@calculator212
Почему некоторые решают рабоатать с бд на чистом sql
В целом есть несколько причин:
1) В целом ORM в го не очень удобные, тот же gorm особо не даёт выигрыша в простоте относительно sql
2) В целом запросы могут быть относительно простыми и ORM не нужна
3) Нет стандартной ORM по типу Hibernate, SQLAlchemy
4) В го у ORM есть ограничения,
5) Если ORM на основана на рефлексии то она будет медленно работать (привет gorm) даже для средненагруженных проектов, не говоря про highload

В целом многие используют штуки по типу sqiurell, и sqlc, т.к. они легче чем ORM и для ряда вещей упрощают код. Для миграций в большинстве проектов хватит go-migrate
Ответ написан
Комментировать
@gohrytt
Как гофер с 1.13 версии могу предложить следующие рассуждения:

1) Нормальная общепризнанная и безболезненная ORM отсутствует. Самая популярная - GORM, где-то на втором месте - ent. Обе в целом как-то соответствуют ожиданиям, но имеют свои особенности. Кто в GORMе делал джоин - в цирке не смеется.
2) Из за того что в большинстве нормальных проектов ORMы не используются очень быстро привыкаешь писать именно SQL. Ты ещё на стадии аналитики рисуешь все эти create table и select from в голове, потом просто вставляешь в код.
3) Производительность GORM сделала в мире го репутацию всем ORMкам как очень плохому решению.

Лично я делю всех гоферов на 4 типа: бывшие джависты, бывшие пхпшники, бывшие питонисты и непосредственно гоферы - те у кого го первый или основной язык. В большинстве наблюдаемых случаев ORM в го пытаются затащить бывшие джависты по старой привычке: вот у нас в спринге был ORM значит и здесь возьмём. Клинический случай - когда такой бывший джавист становится тим или тех-лидом и делает ORM обязательным. Сколько видел таких случаев - каждый раз в результате команда ходит плюётся.

Ну и да, есть ORMки основанные на генерации кода, но самая популярная - GORM основана на рефлексии и иногда магии, это очень сильно бьет по производительности и иногда может стать "бутылочным горлышком" приложения.
Ответ написан
@igaraev
Я работаю DBA, и вот что я вам могу рассказать об ОРМ из своей практики, язык особо роли тут не играет. SQL как язык программирования декларативный, то есть мы ему говорим какую информацию он должен нам дать а метод извлечения он придумывает сам, и далеко не всегда он это делает оптимально, на это есть много веских причин. Опытный программист может написать оптимальный sql запрос, а orm зачастую нет. Ещё из минусов орм это сложный поиск источника проблем. Был случай база нереально стала тормозить, Я нашел проблемный запрос который ддосил базу. Запрос был с синтаксической ошибкой, и его таким сгенерировано орм, программисты откатили сборку и отказывались верить что это их программа. Через месяц они нашли место где орм генерирует этот sql.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 7
@Superclip
1. В случаях, когда данных много и запросы тяжелые. Требуется оптимизация, управление джойнами, хинты и прочее.
2. К п1. Чтобы перенести обработку поближе к данными.
3. В случаях, когда бизнес логика размазана и ее часть приходится на БД (всякое в жизни бывает). Тогда SQL становятся большими и сложными - их проще писать на SQL. ORM в этом случае приносит лишнюю сложность.
Ответ написан
@killnet
На мой взгляд одной из причин является то, что не все при разработке используют парадигму ООП
Ответ написан
Комментировать
@Rerurk
Go это простота и скорость. Зачем иметь бутылочное горлышко в виде orm
Ответ написан
@JavaDok
Я джавист, за го не скажу.
1. ORM легче поддерживать один раз написал можель и у тебя есть репозитории в которых уже реализовано куча стандартного функционала
2. Можно расширять функционал , в современных орм оибах очень круто развит. Дсл по этому все написанное легко может прочитать другрй программист нежели разобраться в партянке sql
3 репозитории поддерживают нативный sql что позволяют некоторые вещи написать на нативном языке при этом Ты можешь сказать, какая модель в результате тебе нужна или массив моделей - опять же спасибо орм. 4 В общем у нас spring data jpa мощнейшея вещь , код пишется быстро, понятно а если врубить дебаг то в консоле увидешь что это переводится на понятный язык sql
5 производительность та же. Исключения составляют моменты когда человек не умеет пользоваться орм вообще и косячит на каждом углу - для этого и придумали собесы чтобы подобный контингет отсеять и не взять на проект.
Ответ написан
@comdivuz
Основной стек был Java/Kotlin, сейчас Go - база основная Postgres. Продукты сервисные и внутренние, задачи адаптации и совместимости сразу под многие движки нет.

Ни там ни там не использовали ORM (точнее во времена Spring использовали и гибернейт и JPA и еще что-то, но от всего отказались). Иногда пилим "свой ORM", обычно это кодогенерация (из Yaml и в SQL и в GO) и обслуживает конкретный проект - это делается если система действительно сильно классическая базо-ориентированная и там сплошной CRUD.

Поясняю почему не ORM, точнее поясню почему никакие "фишки" ORM-движов нам не только не нужны, но и вредны некоторые.

1. Переносимость между БД - этой задачи не стоит, у нас не внешние продукты для самостоятельной установки куда угодно, у нас четкий стек баз и есть компетенции их использовать более продвинуто и с использованием всех возможностей, больше чем предлагает ORM
2. Автоматические миграции из кода - это вообще зло - ни один движок не порождает действительно хороших внятных схем, с доменами, дефолтами GENERATE AS, partition by и прочее, никто также не терпит автомиграций только от наката какого-то микросервиса в стек, миграциями управляем очень осторожно как отдельным процессом, тем более в микросервисной архитектуре обычно нет никакого "владельца" одного базы из сервисов
3. Мапинг кортежей в структуры - это на самом деле совершенно не сложно и свои, причем более удобные по поведению прокладыки пишутся за час и складываются в общую библиотеку и там можно лучше зарешать какие-то преобразования в DTO
4. Что касается самих запросов - мы обычно оптимизируем базы вьюхами, функциями и т.п. и соответственно одни и те же структуры порой запитываются из разных источников, то же самое касается кэширования, связывания сущностей и т.п. - базовые вещи легко кодогенерятся и не требуют никакой прослойки библиотечно, сложные все равно писать ручками в хитрые запросы
5. Всякие там каскадные обновления и множественные вставки - по факту это только от лени и в учебных проектах - это все так здорово. на деле лучше немного помучиться и сделать более внятные и явные бизнесовые операции по обновлению данных

Итого - ORM бы дал нам выигрыш если бы требовалась переносимость, если бы проекты были бы совсем рутинные и если бы не было компетенций по работе с БД. Для сложных внутренних проектов с наличием квалифицированных разработчиков БД - ORM как пятая нога собаке.

Еще раз подчеркну - в контексте - ORM - как "некая либа которая делает ORM и такая няшная, все умеет", если мы говорим про ORM как тип операции (Object Relation Mapping) то естественно такие операции есть и вспомогательные функции для этого тоже.
Ответ написан
Комментировать
Ответов уже дали довольно много, но хотел дополнить, что с raw sql в Go можно очень удобно работать через библиотеку sqlc, которая по переданным sql-файлам с запросами и папкой с миграциями (или sql-файлом со схемой БД) генерирует Go-шный код – структуры запросов/ответов, типы и т. д. А также валидирует корректность запросов относительно схемы БД. Итого, уходит большинство проблем, которые обычно решает ORM, да и риск "накосячить" с raw sql становится минимальным.
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Скорее всего - специфика Go-задач.

Дело в том что область применения ORM обычно ограничивается CRUD приложениями.
И если мы заходим в область утилит для ETL и BigData то там оказывается что ORM вообще не нужен.
Там работают во первых диалекты SQL, (Spark-SQL, Hive-SQL, MS U-SQL). Во вторых дизайн
entities очень громоздкий (по 500-1000 колонок). И эти колонки еще и двигаются во времени
следуя schema evolution на ходу. Тоесть добавляя новые колонки и расширяя типы от узких к широким.
Представить себе ORM в таких условиях просто невозможно. Кроме того ORM кеширует объекты
в коллекциях языка а это, сами понимаете не вопрос Bigdata и аналитики.

Вообще ORM - это пугало, которым пугают на собеседованиях новичков. Для java-junior знание ORM - уже
приравнивается к знанию сопромата и философии Конфуция. Знаешь ORM - получи должность
в банке и сиди себе с умным видом на митинге.

С моей точки зрения ORM ограничивает сильно в оптимизации запросов. Хинт уже так просто не поставить.

Кроме ORM (Object-Relational-Mapping) есть и другая философия. Не от объектов к реляциям а наоборот.
От базе к объектам. (Фреймворк MyBatis например). В нем причинно-следственная связь перевернута.
Сначала таблицы и хранимые процедуры существовали в БД и уже потом, a posteriori, разработчик
описывает для них мапппинги в обратном направлении.

Существует также миф о том что ORM позволяет лихо прыгать по разным базам. Ни разу я для себя этот
миф не подтвердил. Чем крупнее система - тем плотнее она сидит на лицензии от DBMS, и тем глубже
она использует фичи этой DBMS (язык хранимых процедур особые режимы таблиц и партишенинга)
и совершенно нет никакой надежды что миграция произойдет в один мышко-клик. Скорее наоборот.
Миграция - это боль и слёзы и крупные платежи сектору разработки и облачным провайдерам.
Баги и просадки перформанса в самых неожиданных местах БД.

Хотя для вашего pet-project ORM вполне удобен особенно когда вы тестируете например веб-приложуху
на H2 в перспективе с переходом на Postgres.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы