Генераторы 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. Переименовал столбец, а миграция его решила пересоздать. И сразу у всех дела появляются - бэкапы искать, релизы откатывать.

Кстати в рамках «просто изучить SQL». Какой именно ты предлагаешь мне учить? PGSql, T-SQL для MSSQL, для MySQL, для SQLite? А может отдельный диалект для Oracle? Такие штуки как генераторы и ORM и скрывают от тебя мелкую специфику, позволяя сосредоточиться на модели данных. Опять же, я могу протестировать код на SQLite, а работать он будет уже в другой СУБД, а мне и надо поменять драйвер на нужный (ну почти).

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

Такие штуки как генераторы и ORM и скрывают от тебя мелкую специфику

Мелкую - скрывают, серьёзную - просто не умеют использовать. А ты, если будешь писать запросы сам, сможешь.

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

Каждый из sql-серверов считает что именно его синтаксис лучше всего позволяет сосредотоиться на этой самой модели данных. Осталось только выбрать.

именно его синтаксис лучше всего

Шут с ним, с синтаксисом. Они ж ведут себя по-разному при внешне одинаковом синтаксисе.

я могу протестировать код на SQLite, а работать он будет уже в другой СУБД

Удачи.

CREATE TABLE lor251011 (a text, b text);
INSERT INTO lor251011(a,b) VALUES ('test', 'i am postgresql'),(NULL,'i am sqlite');

SELECT b FROM lor251011 ORDER BY a LIMIT 1;

Если говорить про питон, там есть алхимия (орм) + алембик (генератор миграций), вот второй как раз следит за состоноянием схемы в ОРМ и в автоматическом режиме генерирует миграции - up/down скрипты. Ну естественно не всегда корректно и сложные случаи например, с переименованием колонок надо описывать вручную, но все же ОРМ упрощает миграцию схемы. Как там в Го не знаю, наверно есть подобные проекты.

И как тут ORM поможет? Оно сделает селект без лимита и отсортирует всё само?

Вот понятия не имею.

Я ж говорю - я и есть ОРМ. Только с руками, ногами и на зарплате.

И всяких таких фенечек знаю предостаточно, чтобы тупо не верить в «берем ОРМ и не думаем об особенностях реализаций СУБД».