Генераторы SQL и ORM в разработке

Генератор sql это штука, которая транслирует запрос с неспециализированного языка общего назначения в специализированный язык запросов к базе? Смотри: написание запросов на неподходящем для них языке уже портит эффективность данного занятия и ограничивает возможности полноценного использования базы, а автоматический транслятор ещё и зачастую создаёт неэффективные запросы там, где ты легко мог бы написать сам нормально. Ты уверен что это тебе нужно, вместо того чтобы просто изучить sql?

Я знаю sql, но не хочется смешивать в коде несколько языков как это было с Java времен JDBC.

То есть ради декоративных заморочек ты готов костыльно писать запросы на неподходящем для них языке?

У тебя есть опыт работы с СУБД в Go? Если да, чем пользуешься? Можно примеры кода, если не жалко, интересно посмотреть.

Не, к go я не прикасаюсь. Ладно, оставлю тему.

Это, к моему сожалению, не декоративные заморочки. Они все взбесились с запихиванием работы с БД в прокрустово ложе их понятий о CI/CD и прочих гитов.

И когда контора ORM не хочет, но хочет чтобы БД жила по SemVer и веткам, как обычный код; и крутить её в любую сторону туда-обратно - ей-богу лучше бы контора ORM хотела.

У нас во всех сервисах используется либо чистый SQL, либо query builder’ы (реже).

Как с SQL Injection боретесь? Что за билдеры?

Как с SQL Injection боретесь?

Полагаю, так же, как и лет 20 назад — параметризованными запросами.

Ye old plain SQL.

Жесть.

Эм, а в чём проблема схему базы (на sql) в репу засунуть?

Реалии жизни. ORM может быть достаточно для тривиальных вещей. В реальной же жизни проще использовать специализированный DSL для запросов к DB.

ORM вообще никак не освобождает от необходимости версионировать схему БД.

ORM вообще никак не освобождает от необходимости версионировать схему БД.

Зато значительно упрощает это дело. Прям на порядки. Знаю о чём говорю, т.к. поддерживал большой проект, в котором изначально версионирование было на голом SQL. Это была боль.

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

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

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

Клиенту1 ушла версия Продукта2.1, а Клиенту2 версия Продукта3.5 и их обе надо поддерживать с upgrade и downgrade в рамках мажорных версий.

И вот ты не «разработчик БД», ты «индус-заменитель-ОРМа по написанию миграций». А с учетом, что запросы оформлены процедурами - каждая «миграция» вниз/вверх - это две миграции общим объемом кода, большим чем голая схема БД.

-----------

Правда это пока только перспектива. Общее направление, так сказать. Задницей чую - лучше бы они робота использовали вместо индуса на дальней дистанции.

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

Клиенту1 ушла версия Продукта2.1, а Клиенту2 версия Продукта3.5 и их обе надо поддерживать с upgrade и downgrade в рамках мажорных версий.

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

https://github.com/mattermost/squirrel

Ну да, смотрю что там как. Спасибо.

sqlc, goose

только сегодня задавался аналогичным вопросом. нагуглил gorm и gen

до практики, правда, пока не дошел

Ты не прав. Там всегда есть возможность голый запрос написать и замапить результат на какую-то структуру (вернуть сущности определённого класса)

Использовать голый или обертку, зависит от сложности запросов.

Если запросы простые, то можно делать через ORM или что-то подобное.

Если сложенные (GROUP BY и прочее WITH) то, лучше всего писать через слой доступа к данным на голом SQL.

Ну и по необходимости можно смешать.

Эм, а в чём проблема схему базы (на sql) в репу засунуть?

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