Live data from Hacker News

SQL looks like English is a well intentioned error

github.com

21–24 of 24 posts

Re: SQL looks like English is a well intentioned error

#21
post #15

Earlier quoted context omitted.

The things with SQL is that it's more like parroting RelAlgebra instead of trying to implement it with a comfortable syntax. All the bad ideas of the Cobol language generation come with it. And, like you said, SQL kills one of the core ideas of RelAlgebra: composability. I find it very sad that behind the scenes in most relational DBs, the mess off SQL gets translated to the operator language which the optimizer work…

The optimizer does not work work on pure relational algebra. Or works on something very similar to SQL in the case of PostgreSQL.

The operators in PostgreSQL used to represent something that feels a lot closer to rel algebra than SQL.

Admittedly, I haven't looked at pgsql code for 10+ years so this could have changed.

Re: SQL looks like English is a well intentioned error

#22
While I don't agree with the conclusion of the article, I still wonder if there's an alternative to SQL that is:

- declarative

- easy to understand

- scales well with the complexity of the query

Perhaps it could look and feel like a functional programming language but underneath uses the same execution engine as SQL

I've seen a few attempts at it, but none of them have clicked with me.

Thoughts?

Re: SQL looks like English is a well intentioned error

#23
post #3

I am no fan of the syntax of SQL, however the authors solution of making SQL more procedural is (imo) correctly identifying an issue but then reaching for the wrong tool to fix it. When I am authoring SQL, I find the declarative and relational concepts extremely powerful and well suited to the problem I am solving.

As long as I am allowed to write keywords in capital case I am fine with the syntax. I kinda like it. It smells like the 70s.

I enjoy how it builds on previous success WITH its use of regex. There is nothing quite LIKE ideas from the 50's haunting you in your sleep.

   SELECT age FROM Customers WHERE Country='Mexico'
Could be written something like:

   table.customers.filter(c=>c.country == "Mexico").age
The filter is kinda ugly, there is this strange assumption there to be only one Mexico in country.

Clearly the most advanced approach is this:

  //customer[country="mexico"]/age
1999!
Post reply on HN