⚠️ Набрасываю на SQL

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

Так вот, я вчера мозг сломал в трёх местах, пока пытался написать запрос с элементарной фильтрацией по колонкам с таймстемпами. Не то что бы это что-то сложное, но способов выразить время и фильтры по времени в PostgreSQL миллион (как и положено в SQL). А к ним добавляется ещё неясность относительно того, как эти даты и интервалы правильно передавать конкретному драйверу — авторы того драйвера, что у меня решили, что не будут делать авто маппинг time.Duration в интервалы. Почему? Потому что не будут.

Вообще я думал про то, что в СУБД нужно выкинуть/сделать SQL опциональным и предоставлять бинарный протокол. Почему SQL нужен аналитикам — понятно. Зачем промежуточный язык для продакшен-кода — мне непонятно. Если бы у СУБД существовал бинарный протокол, то язык запросов мог бы быть выражен инструментами языка, на котором ведётся разработка. Да, я знаю про ORM и ActiveRecord. Но они всё равно превращают код на одном языке в код на SQL. Тут уж я скорее солидарен с го-коммьюнити — если и писать SQL-запросы, то на самом SQL.

Есть тула, на которую я недавно наткнулся — sqlc. Она отчасти, но решает эту проблему: вы описываете схему БД, как обычно вы это делаете в миграциях на создание таблиц, а дальше sqlc генерит код. Сгенерированный код реализует только CRUD, но при этом никто не мешает в отдельном файле рядом дописать к структурам методы, которых вам не хватает. В sqlc нравится, что это не ORM, а именно кодогенерация — при необходимости с sqlc можно будет постепенно без проблем съехать или, например, подменить части сгенерированного кода (засчёт эмбеддинга и прочих танцев, но всё равно). Выкинуть ORM просто так уже не получится.