https://antonz.org/fancy-ql/

[logo]   Anton Zhiyanov
blog contacts ru
[                    ]
I Don't Need Your Query Language

This post may seem a bit harsh, but I'm tired of the "SQL shaming"
that has somehow become a thing in the industry. I have a right to
disagree, don't I?

Every year or so, a new general-purpose database engine comes out.
And that's great! It can bring new valuable approaches,
architectures, and tools (plus, building database engines is fun).

Often this new database engine comes with a new query language. And
that's probably good, too. Or maybe it's not.

Simple and elegant

An elegant query language for a more civilized age Oh, it's elegant
and civilized? Sure, I'll bite.

What puzzles me is that every time the authors claim that having this
brand-new query language is somehow a strength. It's not. It's a
weakness. Learning a whole new language just to query your database
is a burden. I don't want to do that.

We already have a common ground language for general-purpose
databases. It's called SQL. I'd rather use it with your database.

 I'm not talking about software that targets a specific narrow
domain field. Having a separate domain language for specific use
cases makes perfect sense.

Sure, your language is elegant. That doesn't help me. First, it's
still easier to write a slightly longer query in SQL than to learn a
new query language. Second, your supposedly simple language will
become complex anyways -- as soon as I try to solve real-world tasks
with it. So why bother?

Better than SQL

A comparison that speaks for itself Just look at that ugly SQL beast.

Sometimes the authors of a new query language try to frame SQL as
terribly complex. Let's take an example from one of these "post-SQL"
databases. A comparison that, according to the authors, speaks for
itself.

 I'm using a particular "post-SQL" database (without naming it) to
illustrate my point here, because its landing page is a vivid example
of "SQL shaming". This is not a criticism of the database or its
authors. I'm sure it's a great product.

FancyQL:

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

SQL (as the authors of FancyQL see it):

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 (as it may be):

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

Hmm. Another example?

FancyQL:

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

SQL (as the authors of FancyQL see it):

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 (as it may be):

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

A bit verbose. But maybe SQL is not that complex after all?
Otherwise, why would you paint it scarier than it really is?

Modern

Designed for devs, not suits Let's throw in some suite-shaming!

Here is another common argument:

    SQL was designed with 1970s businessmen in mind, and it shows.

True, SQL was designed in the 1970s. But how is that a weakness?
Everyone knows SQL. All major database engines support SQL. SQL is
expressive enough to solve any data-related task. SQL has a solid
standards committee that maintains and improves it. What can your
language offer besides being created in the 2020s?

I can go on, but I don't think it's necessary. My point is simple.

I don't need your fancy query language. I'd stick with SQL.

Maybe it's just me.

Follow @ohmypy on Twitter to keep up with new posts 

17 Jun, 2023
data 

- Python's sqlite3 with extensions

See also

Covering Index in SQL

SQL Recipe: Compare with Neighbors

LIMIT vs. FETCH in SQL

  * Subscribe: Twitter GitHub LinkedIn RSS
  * Email: m@antonz.org