SQL: time to retire?

SQL is quite possibly the oldest language in wide use today. It begs for changes or even complete replacement, but the entire area of databases somehow remains very uninviting for innovation and paradigm shifts. Why? Good question, I don't know, and I don't think I care either...

Oh, and maybe that's the answer?

With the exception of a small group of highly skilled engineers who develop DBMS systems (and then that's not exactly database programming), the rest of the field is relatively low-skill, low-barrier, mostly non-engineering niche that doesn't look very attractive to, let's say, more or less accomplished, skilled engineers. I mean, of course you can use databases in your projects, but that's not your main expertise, neither you want it to be such, right? (Or if it is, I'm afraid this blog post is not for you).

Anyway... A few thoughts on SQL.

I'm sure many programmers would admit that they never liked SQL from the aesthetical point of view but they'd at least acknowledge its expressiveness and conciseness. I have great doubts about both.

Let's say you have a programming language that can handle persistent data, i.e. you declare variables and mark them as persistent, which means values assigned to these variables survive program reboots. We are interested in one particular case: a persistent array of structures (objects). That's a database table, essentially. Let's say the language is something Python-ish and let's try to express this queer construct:

SELECT customers.name, countries.name FROM customers
    LEFT JOIN countries ON customers.country_id=countries.id
    WHERE customers.id=2

in our shiny new magical language:

c = customers[2]
print c.name, countries[c.country_id]

Isn't it neat? I think the compiler can easily figure out what's required here and translate this piece to low-level database operations involving indexes if needed. Moreover, the entire epic of ID's and relations can be eliminated by some automatic object reference infrastructure that performs translations of run-time references to database ID's and back. Having that in mind, can we, as a slightly more complicated example, select and print multiple rows? Of course we can:

for c in customers:
    if not c.suspended:
        print c.name, c.country.name

Would you rather prefer the awkward, limited and unaesthetic SQL after seeing this?

We'll probably talk more about this idea some other time, but meanwhile I'd suggest a little fix to the existing SELECT statement. I think a small syntactic change like this:

SELECT FROM table GET column1, column2, ... WHERE ...

would make SELECT consistent with INSERT INTO table SET... and UPDATE table SET..., and besides, it would make command completion in the SQL shell perfectly possible: when entering column names after GET, the shell knows already in which tables to look for suggestions.

That's it for now. I think I'll gradually elaborate the idea of an imperative language with persistent data, because it sounds fantastic and pretty feasible.