Just Learn SQL

Через третьи руки я получил интересную ссылку: What ORMs have taught me: just learn SQL. Статья интересная и в целом повторяет все то, о чем я говорил у себя в блоге. ORM – это игра, в которую невозможно выиграть. Она завязана на том противоречии, что в ORM продвинутые средства SQL недоступны. А если пользоваться только доступными средствами, то либо их не хватает, либо возникает лишний код в приложении.

Хотя все это очевидно, находятся те, кто не верят. Однако не обязательно верить мне или автору – можно обратиться к нейтральным источникам, которым не свойственны подтасовки.

Напомню, в Кложе есть два подхода для работы с SQL. Первый – библиотека Hugsql с очень простым принципом. Вы пишете сырой SQL, который позже становится функцией. В эту функцию передают подключение и параметры, а внутри выполняется тот SQL, что вы написали. Он может быть сколь угодно сложным и относиться к какому угодно диалекту: библиотека просто передает его драйверу и возвращает результат.

Второй вариант – библиотека HoneySQL для построения SQL из данных. Это еще не ORM, но уже шаг в данном направлении. Например, передаешь в библиотеку словарь в вектором векторов словарей, и получается SQL. Болванку запроса легко строить по условиям или на базе каких-то других данных.

Так вот, интересен следующий факт. В библиотеке Hugsql последний коммит был два года назад и касался документации. Всего коммитов около 200. В отношении кода изменения были четыре-пять лет назад. Активных фаз у проекта всего две: в 2016 и 2022 годах, при этом число коммитов в это время измеряется десятками.

С HoneySQL ситуация другая: коммиты и релизы выходят постоянно. Всего коммитов около 1400. Шон Корфилд (автор проекта) уже давно развивает HoneySQL, при этом динамика проекта противоположная: коммиты и релизы выходят все чаще. В Слаке регулярно приходит народ и просит добавить ту или иную фичу какого-то диалекта: хитрую агрегацию этой базы, приведение типа другой базы и так далее.

Доходит до того, что один диалект ворует возможности другого. Например, я использовал недокументированные возможности HoneySQL, чтобы строить JSON Path в Postgres, например, что-то вроде

where doc @@ '$.path.to.attribute == "some-value" '

В одном из релизов все отвалилось. Оказалось, к Шону пришел какой-то тип и сказал: давай сделаем пути JSON для SnowflakeDB. В этой самой Snowflake другие кавычки и разделители, которые не дружат с Postgres. Мои решения превратились в тыкву, и пришлось экстренно исправлять.

К чему это все: выразить SQL на языке, отличном от SQL, в целом невозможно. Проект HoneySQL это подтверждает: даже не смотря на активную разработку, найдутся такие потребности, которые нельзя выразить списком словарей – а если и можно, то это долго и непонятно. У библиотеки Hugsql такой проблемы нет: пиши что считаешь нужным, она только передает запрос драйверу – то самое “just learn SQL” из заголовка статьи.

Конечно, для удобной работы нужны оба средства, однако важно понимать приоритеты. Чтобы выразить SQL в виде чего-то – ORM или DSL – нужно понимать SQL. При этом часто оказывается, что знания первого достаточно.