Live data from Hacker News

A Short Story About SQL’s Biggest Rival

holistics.io

21–30 of 128 posts

Re: A Short Story About SQL’s Biggest Rival

#21

Really the the only issue I have with SQL is NULL != NULL. This creates an impedance mismatch with most languages... MySQL sort of solves this problem with a operator, which I wish was the default for ORMs to use. There are a lot of other minor nitpicks but a lot of criticisms come down to the actual RDMS not SQL itself.

What about the main point of the article that SQL is not composable.

CTEs (common table expressions) and views definitely do help with this, though they are new-ish where they exist and often have optimization issues. But being able to use them extensively in a newer database where they work well helps this quite a bit.

Re: A Short Story About SQL’s Biggest Rival

#22

Earlier quoted context omitted.

What about the main point of the article that SQL is not composable.

CTEs (common table expressions) and views definitely do help with this, though they are new-ish where they exist and often have optimization issues. But being able to use them extensively in a newer database where they work well helps this quite a bit.

Tables are composable but the expression itself cannot be decomposed. I cannot reuse a where clause somewhere else; that is the fundamental problem the article addresses.

Re: A Short Story About SQL’s Biggest Rival

#23
post #2

Dupe: https://news.ycombinator.com/item?id=24709031 As I said the last time this came around: The end of this isn't quite right. The Postgres project started in 1986. I don't recall what language it used, QUEL perhaps, but it wasn't SQL. SQL support was added between 1994 and 1996, and that's when PostgreSQL was born.

Postgres used PostQUEL. SQL was added to Postgres by one of Stonebreaker's graduate students (Andrew Yu) around '95. By '95 Stonebreaker's lab was already working on a new distributed Postgres called Mariposa.

Re: A Short Story About SQL’s Biggest Rival

#24

>If the world worked differently, we wouldn’t still be writing on QWERTY keyboards, or speaking English; technically superior alternatives like Dvorak and Esperanto would have taken over. Bad metaphor: There is no evidence for Dvorak's technical superiority to QWERTY, neither is there for Esperanto over other languages.

[deleted]

Re: A Short Story About SQL’s Biggest Rival

#25
can anyone find examples of what QUEL looked like?

If we had a more composable query language being used instead of SQL, I wonder if that would have effected the course of ORMs, which arguably end up being as much about composable models of queries as they do about actual object mapping.

Re: A Short Story About SQL’s Biggest Rival

#26

Really the the only issue I have with SQL is NULL != NULL. This creates an impedance mismatch with most languages... MySQL sort of solves this problem with a operator, which I wish was the default for ORMs to use. There are a lot of other minor nitpicks but a lot of criticisms come down to the actual RDMS not SQL itself.

I just wish they had flipped from and select around.

Re: A Short Story About SQL’s Biggest Rival

#27

Really the the only issue I have with SQL is NULL != NULL. This creates an impedance mismatch with most languages... MySQL sort of solves this problem with a operator, which I wish was the default for ORMs to use. There are a lot of other minor nitpicks but a lot of criticisms come down to the actual RDMS not SQL itself.

I just wish they had flipped from and select around.

Or "set" and "where"

Re: A Short Story About SQL’s Biggest Rival

#28

Really the the only issue I have with SQL is NULL != NULL. This creates an impedance mismatch with most languages... MySQL sort of solves this problem with a operator, which I wish was the default for ORMs to use. There are a lot of other minor nitpicks but a lot of criticisms come down to the actual RDMS not SQL itself.

I just wish they had flipped from and select around.

It's not about flipping. The two concepts are actually commutative. You could in theory create syntax that looks like this:

  FROMCLAUSE * SELECTCLAUSE * WHERECLAUSE = SQLEXPRESSION
  SELECTCLAUSE * WHERECLAUSE * FROMCLAUSE = SQLEXPRESSION
  ...
The issue is that not only does SQL syntax force an artificial order on these clauses, but that these clauses Cannot be decomposed to be used elsewhere. I cannot reuse a WHERECLAUSE or a SELECTCLAUSE in another expression.

Re: A Short Story About SQL’s Biggest Rival

#30
> … The language (SQL) is not very composable. This is a fact that most SQL users are not aware of. The relational algebra that SQL is based on is absolutely composable but SQL is not due to the inherent limitation of the language (as it was designed to be natural language-like). When you write "select x from a where z", you are actually building something along the lines of "from a" => "where z" => "select x" in the algebra and you can actually compose each portion separately. If you are familiar with dplyr, Spark or pandas you would get this instantly.

Hmmm. Not a big lover of SQL, but this is a bit imprecise. While the unit of composability is slightly smaller for from=>where=>select (expression) vs select+from+where (subquery), in practice they both encode the same fundamental compositional principles, based on relational algebra. Any from=>where=>select query can be translated into a select+where+from query almost 1:1, if only via:

    from t ::= select * from t
    q => where p ::= select * from q where p
    q => select xs ::= select xs from q 
Sometimes the select+where+from ends up more verbose, sometimes there is more brain twisting to grok a given select+where+from query, but that's not a composition limiting factor. Granted, the readability of SQL is sometimes lacking, but it is fully capable to compose recursive relational algebra queries.
Post reply on HN