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

Question

[Reynir]

Почему некоторые решают рабоатать с бд на чистом sql это дает больше возможностей или ?

Comments

[Everything_is_not_so_bad]

Для самоутверждения
Хочется острых ощущений
Это круто
... (продолжить)

[Everything_is_not_so_bad]

Ответ от ИИ

Ответ на ваш вопрос может быть несколько субъективным, но я постараюсь объяснить общие причины, по которым некоторые программисты предпочитают работать с базами данных на чистом SQL.

• Более точный контроль над запросами: SQL позволяет более точно контролировать запросы к базе данных. Это означает, что программисты могут написать запросы, которые точно соответствуют их потребностям, без необходимости адаптировать их к ограничениям ORM (Object-Relational Mapping) или других абстракций базы данных.
  
• Лучшая производительность: Иногда SQL может обеспечить лучшую производительность, чем ORM, поскольку он позволяет создавать более оптимизированные запросы.
  
• Более простая отладка: Когда что-то идет не так с запросом к базе данных, отладка на чистом SQL может быть проще, чем отладка запросов, сгенерированных ORM.
  
• Более гибкое проектирование баз данных: Работа на чистом SQL позволяет проектировать базы данных более гибко, чем многие ORM, которые могут иметь определенные ограничения и требования к структуре базы данных.
  
• Более глубокое понимание баз данных: Работа на чистом SQL может помочь программистам лучше понять, как работают базы данных, и может быть полезна для разработки более сложных и эффективных решений.
  

[calculator212]

Everything_is_not_so_bad,

Для самоутверждения
Хочется острых ощущений
Это круто

Вы писали на го, когда-нибудь?

[Everything_is_not_so_bad]

calculator212, ага. А что?

[calculator212]

Everything_is_not_so_bad,

ага. А что?

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

[Everything_is_not_so_bad]

Ого, какой горячий вопрос!

[Everything_is_not_so_bad]

calculator212,

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

я не работал с ORM в Го. Только с расширением для SQL: github.com/jmoiron/sqlx

SQL хорош тем, что это ISO стандарт и его должны знать все, кто работает с СУБД, в отличие от ORM, где в каждом есть свои наименования и особенности реализации, которым стоит следовать, что привносит немало ограничений. Но есть и свои бонусы.

[Everything_is_not_so_bad]

Кстати, никто белку (squirrel) не упоминал - query builder.

[calculator212]

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

Answer 1

[Василий Банников]

Не гошник, но расскажу в целом.
1. На 1 уровень абстракции меньше. При работе с ORM нужно думать одновременно и об особенностях твоей ORM-ки и об особенностях базы.
2. На сыром SQL некоторые вещи сделать проще, чем с ORM-ками.
3. Лучше сырой SQL, чем тупая ORM-ка.
4. Некоторые ORM-ки могут негативно влиять на производительность.

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

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

Нормальные ормки я пока видел только:
1. В C# из-за Linq
2. В Rust из-за макросов.

Comments

[Everything_is_not_so_bad]

Нормальные ормки я пока видел только:

а "нормальные" они по каким критериям?

[Everything_is_not_so_bad]

А query builder под какую категорию подпадает? "Тупой" ORM?

[Василий Банников]

Everything_is_not_so_bad,

а "нормальные" они по каким критериям?

1. Защищают тебя от опечаток и делают ряд проверок во время компиляции.
2. Поддерживают строгую типизацию
3. Поддерживают специфику конкретных субд.

А query builder под какую категорию подпадает? "Тупой" ORM?

query builder - это собственно query builder.
Это не ORM в принципе, хотя некоторые ошибочно квери билдеры называют ормками.

[Василий Дёмин]

Я бы ещё к критериям добавил, что ORM должна упрощать написание и чтение запросов или хотя бы оставлять их на уровне чистого SQL, а не усложнять. Иногда запрос, сделанный с помощью ORM (именно код на ЯП общего назначения, а не результирующий SQL), выглядит страшнее аналогичного на чистом SQL, пишется дольше и читается хуже.

[Everything_is_not_so_bad]

Василий Банников,
Пункты 1 и 2 можно объединить, пожалуй. А что за ошибки, например?
Ведь понятно, что при динамической типизации ошибки не будут выявлены сразу. Это, скорее, свойство языка, а не ORM. Не так ли?

Это не ORM в принципе, хотя некоторые ошибочно квери билдеры называют ормками.

Вот, собственно, хотел немного потроллить. В целом, они занимают нишу между ORM и чистым SQL.

[Василий Банников]

Everything_is_not_so_bad,

Пункты 1 и 2 можно объединить, пожалуй. А что за ошибки, например?

Опечатки в именах объектов, ошибки синтаксиса в SQL, попытки применить недопустимые операции.

Ведь понятно, что при динамической типизации ошибки не будут выявлены сразу. Это, скорее, свойство языка, а не ORM. Не так ли?

Я допускаю, что могут быть ормки, которые в статически-типизированном языке применяют подходы из динамической типизации. (уверен, что такие есть, но не могу вспомнить ни одного примера).
Ну и в динамически-типизированном языке тоже можно втащить статическую типизацию и при помощи какого-нибудь условного линтера проверять корректность использования ормки.

[Евгений]

Everything_is_not_so_bad, нормальная ORM это описание сущностей(объектов), т.е. по сути это модель, включающая в себя все связанные с ней таблицы. Имеет типизацию, нормализацию, значения по умолчанию, валидацию, т.е. может выдавать ошибки на 'человеческом" языке, если это запрограммировано в сущности, и может преобразовать данных как при записи так и при чтении, может иметь вычисляемые поля и рантайм запросы. Нормальная ORM позволяет работать с данными как с объектом, ну это и из названия следует, собственно.

[varenkine]

По факту!

Answer 2

[Пума Тайланд]

А зачем когда ты сам можешь все контролировать
Тут два основных паттерна
1 когда запросов мало и они простые и ты понимаешь как они работают и никаких косяков со странными данными из вне прийти не должно или ты это уже сам экранироовал , реально намного быстрее напрямую сделать чем вникать в орм
2 когда тебе в каких то частях нужен перформанс или когда орм генерит еретические запросы там где у тебя сложная логика и приходится их переписывать напрямую
Ну и забыл третье вкусовщина

Answer 3

[calculator212]

Почему некоторые решают рабоатать с бд на чистом sql

В целом есть несколько причин:
1) В целом ORM в го не очень удобные, тот же gorm особо не даёт выигрыша в простоте относительно sql
2) В целом запросы могут быть относительно простыми и ORM не нужна
3) Нет стандартной ORM по типу Hibernate, SQLAlchemy
4) В го у ORM есть ограничения,
5) Если ORM на основана на рефлексии то она будет медленно работать (привет gorm) даже для средненагруженных проектов, не говоря про highload

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

Answer 4

[gohrytt]

Как гофер с 1.13 версии могу предложить следующие рассуждения:

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

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

Ну и да, есть ORMки основанные на генерации кода, но самая популярная - GORM основана на рефлексии и иногда магии, это очень сильно бьет по производительности и иногда может стать "бутылочным горлышком" приложения.

Comments

[Ratenti]

А как Kallax, Reform и Sqlboiler?

Answer 5

[igaraev]

Я работаю DBA, и вот что я вам могу рассказать об ОРМ из своей практики, язык особо роли тут не играет. SQL как язык программирования декларативный, то есть мы ему говорим какую информацию он должен нам дать а метод извлечения он придумывает сам, и далеко не всегда он это делает оптимально, на это есть много веских причин. Опытный программист может написать оптимальный sql запрос, а orm зачастую нет. Ещё из минусов орм это сложный поиск источника проблем. Был случай база нереально стала тормозить, Я нашел проблемный запрос который ддосил базу. Запрос был с синтаксической ошибкой, и его таким сгенерировано орм, программисты откатили сборку и отказывались верить что это их программа. Через месяц они нашли место где орм генерирует этот sql.

Answer 6

[Superclip]

1. В случаях, когда данных много и запросы тяжелые. Требуется оптимизация, управление джойнами, хинты и прочее.
2. К п1. Чтобы перенести обработку поближе к данными.
3. В случаях, когда бизнес логика размазана и ее часть приходится на БД (всякое в жизни бывает). Тогда SQL становятся большими и сложными - их проще писать на SQL. ORM в этом случае приносит лишнюю сложность.

Comments

[Everything_is_not_so_bad]

В целом согласен. Однако есть вопросы.

запросы тяжелые

А что плохого в том, что выполнять через ORM? Ведь задержка будет по-любому, вне зависимости от использования ее или нет.

[hogstaberg]

Вопрос не в задержке от самой ORM, а в том, что бывают запросы, которые, будучи написанными в лоб, выполняются очень-очень долго. Но перепиши его немного хитрее и всё начнёт выполняться за доли секунды. Вот в таких случаях ни сама ORM не напишет второй вариант запроса, ни её постоянное использование не даст вам знаний и навыков чтобы понять что тут можно всё сильно быстрее сделать.
SQL изначально был разработан как понятный, относительно стандартный (да-да, есть стандарты, которые ряд СУБД даже соблюдает) и структурированный язык-абстракция для выполнения запросов. Зачем на одну абстракцию, решающую проблему выборки данных, натягивать сверху другую абстракцию? Вы можете сказать: "для возможности в какой-то момент переехать на другую СУБД", но тогда мы приходим к ситуации, что ваша ORM наверняка не умеет в классные специфичные фишки каждой СУБД, а генерирует максимально базовые запросы, которые поймёт любая из поддерживаемых СУБД.

Answer 7

[killnet]

На мой взгляд одной из причин является то, что не все при разработке используют парадигму ООП

Answer 8

[Rerurk]

Go это простота и скорость. Зачем иметь бутылочное горлышко в виде orm

Comments

[calculator212]

Зачем иметь бутылочное горлышко в виде orm

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

[Александр Павлюк]

calculator212, это какие например? ОРМки довольно часто сложные запросы с джоинами бьют на несколько более простых запросов и все начинает работать сильно медленнее.

[calculator212]

Александр Павлюк, конкретно генерация sql это в целом отдельная тема, сложные запросы в целом часто пишут на sql без ORM. В большинстве случаев запросы все же не особо сложные и ORM +/- генерит их нормально. Если говорить про ORM, то есть ent и sqlboiler, но я честно говоря не исследовал их глубоко, т.к. использую sqlc, как по мне конкретно в го проще самому писать запросы, чем использовать орм

[Александр Павлюк]

calculator212, вот sqlc это как раз хорошее среднее между сырыми запросами из кода и полноценной ORM. А ORMы хороши только пока запросы максимально простые.

[Everything_is_not_so_bad]

Зачем иметь бутылочное горлышко в виде orm

А откуда уверенность, что бутылочное горлышко именно в ORM, а не самой СУБД?

Answer 9

[JavaDok]

Я джавист, за го не скажу.
1. ORM легче поддерживать один раз написал можель и у тебя есть репозитории в которых уже реализовано куча стандартного функционала
2. Можно расширять функционал , в современных орм оибах очень круто развит. Дсл по этому все написанное легко может прочитать другрй программист нежели разобраться в партянке sql
3 репозитории поддерживают нативный sql что позволяют некоторые вещи написать на нативном языке при этом Ты можешь сказать, какая модель в результате тебе нужна или массив моделей - опять же спасибо орм. 4 В общем у нас spring data jpa мощнейшея вещь , код пишется быстро, понятно а если врубить дебаг то в консоле увидешь что это переводится на понятный язык sql
5 производительность та же. Исключения составляют моменты когда человек не умеет пользоваться орм вообще и косячит на каждом углу - для этого и придумали собесы чтобы подобный контингет отсеять и не взять на проект.

Comments

[killnet]

Джависты настолько суровы, что даже вопрос читают с конца

Answer 10

[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) то естественно такие операции есть и вспомогательные функции для этого тоже.

Answer 11

[Василий Боднарюк]

Ответов уже дали довольно много, но хотел дополнить, что с raw sql в Go можно очень удобно работать через библиотеку sqlc, которая по переданным sql-файлам с запросами и папкой с миграциями (или sql-файлом со схемой БД) генерирует Go-шный код – структуры запросов/ответов, типы и т. д. А также валидирует корректность запросов относительно схемы БД. Итого, уходит большинство проблем, которые обычно решает ORM, да и риск "накосячить" с raw sql становится минимальным.

Answer 12

[mayton2019]

Скорее всего - специфика 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.