Comment by jyounker | Hacker News Reader

Comment by jyounker | Hacker News Reader

Parent Full thread

> Basically, SQL syntax makes easy things easy. This gets underestimated a lot, indeed people seem to have contempt for it. I think that's a serious mistake.

The flip side of that is SQL makes hard things nearly impossible.

SQL doesn't have facilities for abstraction, and it doesn't compose, and this has consequences that I deal with daily.

The lack of abstract facilities makes it hard to construct complicated queries, it makes it hard to debug them, and it makes it hard refactor them.

Instead of writing more complicated SQL queries, developers lean on the host languages to coordinate SQL calls, using the host language's abstraction facilities to cover for SQL's inadequacies.

The flip side of that is SQL makes hard things nearly impossible.

What about SQL syntax makes the hard things possible? I get that the actual language SQL is broken in all sorts of ways. But I don't see any reason to replace it with some opaque from get-go.

I mean, what stops you from defining, say adjectives and using those for rough modularity.

Say

    EXPENSIVE(T) means T.price > 0;
    Select name FROM books WHERE EXPENSIVE(books);

Seems understandable.

Isn't that just WITH?

    WITH expensive AS (SELECT * FROM books WHERE price > 100)
    SELECT name FROM expensive

Yes, you can extend the language with more syntax. This kind of proves my point.

If there weren't deficiencies then you wouldn't need to define more syntax, and so many work-arounds wouldn't have already been created. The deficiencies in SQL are why each big SQL database ends up creating some procedural-SQL language for use in stored procedures and triggers.

CTEs are close to what you outline above, but even then (as far as I know) you can't name that CTE and use it across multiple statements.

Reply on news.ycombinator.com