Мне не нужен ваш язык запросов

Эта заметка может показаться резковатой. Но я устал от SQL-шейминга, который вижу в отрасли. Я имею право не соглашаться, так ведь?

Новые движки баз данных появляются чуть ли не ежегодно. И это замечательно! Они приносят новые подходы, архитектуры и инструменты. К тому же, разрабатывать СУБД — увлекательное занятие.

Часто в комплекте с новым движком идет язык запросов. Это тоже хорошо, наверно. Или нет.

Простой и элегантный

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

У нас уже есть широко распространенный язык запросов к СУБД общего назначения. Это SQL. Я бы предпочел видеть в вашей базе именно его.

📝 Я не говорю здесь об софте, который работает с какой-то узкой предметной областью. Отдельный доменный язык для конкретного набора сценариев использования — это разумно.

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

Лучше, чем SQL

Иногда авторам нового языка нравится преподносить SQL как нечто ужасно сложное. Посмотрим на примере одной из «пост-SQL» СУБД. Как говорят сами авторы, это сравнение не требует пояснений.

📝 Я здесь использую конкретную «пост-SQL» СУБД (не называя ее), чтобы проиллюстрировать мысль заметки. Промо-страница этой СУБД — такой яркий пример SQL-шейминга, что сложно было пройти мимо. Это не критика самой СУБД или ее авторов. Я уверен, что это отличный продукт.

FancyQL:

select Movie {
  title,
  actors: {
   name
  },
};

SQL (как его видят авторы FancyQL):

SELECT
  title,
  Actors.name AS actor_name
FROM Movie
 LEFT JOIN Movie_Actors ON
  Movie.id = Movie_Actors.movie_id
 LEFT JOIN Person AS Actors ON
  Movie_Actors.person_id = Person.id

SQL (каким он может быть):

select
  title,
  actors.name
from movies
  join movies_actors using(movie_id)
  join actors using(actor_id)

Хм. Еще пример?

FancyQL:

select Movie {
  title,
  actors: {
   name
  },
  rating := math::mean(.reviews.score)
} filter "Zendaya" in .actors.name;

SQL (как его видят авторы FancyQL):

SELECT
  title,
  Actors.name AS actor_name,
  (SELECT avg(score)
    FROM Movie_Reviews
    WHERE movie_id = Movie.id) AS rating
FROM
  Movie
  LEFT JOIN Movie_Actors ON
    Movie.id = Movie_Actors.movie_id
  LEFT JOIN Person AS Actors ON
    Movie_Actors.person_id = Person.id
WHERE
  'Zendaya' IN (
    SELECT Person.name
    FROM
      Movie_Actors
      INNER JOIN Person
        ON Movie_Actors.person_id = Person.id
    WHERE
      Movie_Actors.movie_id = Movie.id)

SQL (каким он может быть):

select
  title,
  actors.name,
  (select avg(score) from reviews
   where movie_id = movies.movie_id) as rating
from movies
  join movies_actors using(movie_id)
  join actors using(actor_id)
where movie_id in (
  select movie_id
  from actors join movies_actors using(actor_id)
  where actors.name = 'Zendaya'
)

movies.sql

Получилось немного многословно. Но так ли уж сложен SQL? Если да, зачем бы вам понадобилась искусственно усложнять его в примерах?

Современный

Еще один распространенный аргумент:

SQL разработали в 1970-х с прицелом на бизнес, а не разработчиков.

Да, SQL разработали в 1970-х. С каких пор это стало недостатком? Все знают SQL. Все основные СУБД поддерживают SQL. SQL достаточно выразителен, чтобы решать любые задачи, связанные с данными. У SQL есть комитет (собранный из представителей основных СУБД), который заботится и развивает его. А что может предложить ваш язык? Кроме того, что изобретен в 2020-х.

Могу продолжать, но, думаю, моя мысль ясна.

Мне не нужен ваш модный язык запросов. Я предпочту SQL.

Может дело во мне, конечно.

──

P.S. Хотите мастерски освоить SQL вместо того, чтобы учить очередной новый язык? Обратите внимание на Оконные функции SQL