Hacker News Reader

Comment by return0 | Hacker News Reader

> SQL seems like a terrible language.

The reason you give is too trivial to justify calling it "a terrible language"

E.F. Codd (author of the whitepaper that is the foundation of all RDBMSs, for which SQL was created to query) was of the opinion that the SQL was a terrible language. His reasoning for saying so are very clearly and well speelled out in several books and articles of his.

That reason is in fact a good one. The order is "wrong" from the point of view of a developer and maybe ok from the POV of the original intent of SQL: The end-user was supposed to run SQL against databases. Few ad-hoc queries, even complicated, can be managed. But using SQL all the time, and the language is clearly the wrong thing to talk to the DB (is like JS: Is what you have instead of what you want).

Also: The fact that everyone run (even if eventually fail) for a ORM instead of SQL, or the way people imagine NOSQL is "better" -is very telling is NO SQL- show this.

The relational model is so simple and powerfull, but SQL is not a good seller of the idea.

Is there another language agnostic option?

I suppose it would be interesting if you could use something like the llvm to target a DB's core features, but through your language of choice.

I haven't seen anything like that, if it exists. SQL is that standard API today, and ORMs provide the language specific implementation (though sometimes in ways that make it inobvious what the generated SQL will look like).

I actually like SQL, but I'm glad people are willing to ask, "Can we do better?" I think for a working programmer, SQL is the only practical choice, but Tutorial D is an interesting attempt to improve (by C.J. Date, described at length in his books Database in Depth and The Third Manifesto), with an open source implementation called Rel. There is also a commercial database called Dataphor that uses D4, a cousin to Tutorial D. There is also a newer project called Andl that is another non-SQL relational query language.

Personally, although I'm not a researcher, I've become intrigued by ways we model change-over-time in relational databases. Snodgrass's book _Developing Time-Oriented Database Applications in SQL_ is a good entry point to all that, and more recently we have SQL2011's Temporal standard. I still have a lot to read here myself, but I am keen to see what happens in the next ten years in how the relational model can incorporate change.

SQL is a lot like JavaScript: a lot of people hate working with it, but it's the only practical choice, as you say.

It's interesting to note that transpiling to SQL is even more popular than the recent trend of transpiling to JavaScript. Every major language has a query builder (many of which end up with syntax similar to Andl). We're abstracting away from SQL and have been for a long time.

With that in mind, I wonder whether we need a new query language so desperately. SQL is so highly optimized in the major RDBMS that any new language would probably compile internally to SQL, meaning it has the same semantics (and is essentially sugar) OR it would be way behind SQL in terms of optimization.

Am I just totally off base here?

After I wrote that comment I thought it might be worth submitting this Andl story to HN about Andl-on-Postgres: [0]. They write, "Relational expressions are converted into equivalent SQL and passed back to the Postgres SPI interface for execution," so you are right about transpiling. But the software world is more mature than it was 20 years ago, so it seems reasonable for a project to get a toehold by building on top of existing systems. That needn't limit its future growth necessarily. It sounds like Andl will work on more than just Postgres, so I can imagine them eventually building a "native" version too. Using existing RDBMSes is a pretty good way to get an MVP though. :-)

[0] https://news.ycombinator.com/item?id=11802917

> Relational expressions are converted into equivalent SQL and passed back to the Postgres SPI interface for execution

I actually don't think I like that approach.

If I transpile my own queries (meaning I use a query builder), then I can cache the generated SQL. There would be some placeholders for arguments, but the query itself doesn't change.

Andl's approach could add significant overhead in certain applications where lots of queries are being executed at once.

And then what happens to EXPLAIN support? Is it harder to debug an Andl query?

Wasn't QUEL a lot better?

I think people use an ORM so that they can "switch data stores". Personally i never used one since SQL is very easy to write and its actually a Standard. Even when i did switch databases, having a standard guarantees there will be fewer changes needed, than if switching orms. Also, what people "imagine" is of zero concern.

In theory maybe. I think instead is looking for a nicer interface (BTW: I learn new languages building a ORM!).

Okay, so another reasons are: that 1) it's terribly difficult to parse and 2) on large tables, messing with query planner is actually more work than just specifying the algorithm you'd like to use. Also: 3) yes, there is an SQL standard, but generally if you're writing any application that uses SQL, you're going to end up writing code for a specific database or use an ORM.

Reply on news.ycombinator.com