Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Critique of SQL, 40 Years Later

carlineng.com

Post reply on HN
Print view View original

191–200 of 260 posts

Re: A Critique of SQL, 40 Years Later

#191

Post by briHass »

tremon wrote: post #133
emaginniss wrote: post #35

Earlier quoted context omitted.

Everyone else is mentioning it from an IDE perspective, but let's also think about logically from a language perspective. When you start a FROM clause and add some JOINs, a few WHERE conditions and maybe GROUP BY, you are building a virtual view of a series of tables, columns, and aggregations. You could even define this data set as an ephemeral table. What you do with that data set afterwards might vary depending on…

You could even define this data set as an ephemeral table Exactly! This is where SQL hurts me the most: not being able to store (partial) query expressions in variables for later reuse. The only way to do this is by creating explicit views (requires DDL permissions) or executing the partial query into a temporary table (which is woefully inefficient for obvious reasons).

Isn't that what a common table expression is? Basically a pseudo temp-table to break down queries. Of course, they also allow recursion, which you can't do with a temp table.

Re: A Critique of SQL, 40 Years Later

#192

Post by carlineng »

jakespoon wrote: post #113
adrian_b wrote: post #87

Earlier quoted context omitted.

The title did not refer to years passed since the introduction of SQL, but to years passed since the publication of the paper with the title "A Critique of the SQL Database Language", i.e. from 1984-11. So the title is correct.

Title may be correct. First sentence is totally wrong. Why would I read further?

Author here. Fixed the mistake. You may now proceed with reading the remainder of the post ;)

Re: A Critique of SQL, 40 Years Later

#193

Post by BeefWellington »

isitmadeofglass wrote: post #150
BeefWellington wrote: post #114

Earlier quoted context omitted.

I think this stems from a misunderstanding of the entire point of SQL. It isn't about looking at data in an individual table, it's about retrieving a Result Set for complex queries. All the FROM-first examples I've ever seen are almost universally the simplest query in the world where autocomplete is not a large hurdle anyways because you aren't even bothering with table aliasing. As soon as you do anything even mode…

> I think this stems from a misunderstanding of the entire point of SQL. It isn't about looking at data in an individual table, it's about retrieving a Result Set for complex queries. No misunderstanding at all. It’s just more natural to first describe what the sources of the data are, joins etc, and then afterwards which columns you’d like to retrieve, or what calculations you’d like to perform etc. The current way…

> When it comes to reading order, you never actually know what is selected until you’ve read through the from, where, group by and having clauses anyway, so you constantly have to jump back and forth between dart and end to see the context.

Let's assume this was accurate, and reframe it to discuss putting FROM first in the query:

    When it comes to reading order, you never actually know where what you've selected is coming from until you've read through the WHERE, GROUP BY, HAVING, and SELECT clauses anyways, so you constantly have to jump back and forth between start and end to see the context.
This is equally true if FROM comes first since you have no idea if customer_name in your SELECT way at the end actually comes from a table directly, a subselect, calculation, etc.

I would be interested in seeing what a complex WITH or subselect would look like if you're putting FROM first, and just how much actual clarity you're getting out of reordering it.

I think the benefit is nonexistent and the harm is that you're going to further fragment an already fragmented syntax space for that nonexistent benefit.

Re: A Critique of SQL, 40 Years Later

#194

Post by cryptonector »

cmrdporcupine wrote: post #143
cryptonector wrote: post #119

Earlier quoted context omitted.

Any alternative to SQL has to transpile to SQL in order to gain traction.

Which right away rules out a whole bunch of more sophisticated and elegant behaviours, honestly. The other alternative might be to implement one's new thing as a patch to alter the frontend of Postgres. I looked at this many years ago and the engineering effort was immense. But it might be easier now.

I second u/zasdffaa's question. What behaviors does this eliminate? I'm sure it eliminates some, but I want to hear which ones you're interested in.

Re: A Critique of SQL, 40 Years Later

#195

Post by matheusmoreira »

noirscape wrote: post #53
spprashant wrote: post #27

Earlier quoted context omitted.

If you exploring a set of tables you have never touched before, it really neat if you could just type in: FROM tablename t SELECT t. and some form of autocomplete mechanism, either prefills all the column names from table "t" or suggests the list of columns and/or types associated with it. This is much better than having to: 1. Run a SELECT with LIMIT statement just to get an idea of the layout. 2. Point and click th…

DESCRIBE TABLE is a command that pretty much does exactly this (explain what a table contains) and it's a part of MySQL. If you use PostgreSQL then you can use \d instead. I'm sure the other RDBMSes have their own equivalent (except for maybe SQLite but if you're using SQLite outside of toy environments or hobby projects, you're doing it wrong).

> if you're using SQLite outside of toy environments or hobby projects, you're doing it wrong

https://www.sqlite.org/mostdeployed.html

> Every Android device

> Every iPhone and iOS device

> Every Mac

> Every Windows 10 machine

> Every Firefox, Chrome, and Safari web browser

> Every instance of Skype

> Every instance of iTunes

> Every Dropbox client

> Every TurboTax and QuickBooks

> PHP and Python

> Most television sets and set-top cable boxes

> Most automotive multimedia systems

> Countless millions of other applications

Look at all those toys.

Re: A Critique of SQL, 40 Years Later

#196

Post by xpe »

jokoon wrote: post #47

I wish there were SQL "primitives" functions instead of the SQL language. For example if I want to pick a single row by id, with SQL I must send a query string, which results in parsing, which means lower latency. If I want to randomly select 100k rows among a database of 1 million entries, I need to build 10k query strings (I think?), which won't be fast to parse. I don't think this happens when using C pointers in…

Why 10k queries? You can probably do this with one query.

Re: A Critique of SQL, 40 Years Later

#197

Post by xpe »

Shorel wrote: post #148
gibsonf1 wrote: post #17

I think the issue isn't SQL, but the table paradigm for storing data. Humans do not store data in separate tables that need joining, they store data in a fully connected graph (hyper-graph). Its about relationships and hierarchies - the graph allows incredibly fast hierarchical reasoning, as most things involve hierarchical reasoning. The relational table, and Sql by correlation, are terrible at the human approach to…

It's the other way around. We use tables because they help us to massively simplify the processing of data. Do you want to deal with graphs? The algorithms involved are harder than what your intuition is telling you. In fact, the first databases, before relational databases were in vogue, were hierarchical/network databases. https://en.wikipedia.org/wiki/CODASYL They were obsoleted and replaced when RDMS appeared.

You are talking past the other person... too much certainty, too few questions.

CODASYL is probably not remotely close to what the GP is talking about w.r.t. how humans think in graphs.

Re: A Critique of SQL, 40 Years Later

#198

Post by xpe »

gibsonf1 wrote: post #17

I think the issue isn't SQL, but the table paradigm for storing data. Humans do not store data in separate tables that need joining, they store data in a fully connected graph (hyper-graph). Its about relationships and hierarchies - the graph allows incredibly fast hierarchical reasoning, as most things involve hierarchical reasoning. The relational table, and Sql by correlation, are terrible at the human approach to…

There are more recent aspects of SQL that do hierarchical processing well. Graph processing is often decent depending on the particular DBMS. The syntax and conceptualization of these queries is not as well socialized though.

Re: A Critique of SQL, 40 Years Later

#199

Post by bombcar »

__float wrote: post #110
noirscape wrote: post #53

Earlier quoted context omitted.

DESCRIBE TABLE is a command that pretty much does exactly this (explain what a table contains) and it's a part of MySQL. If you use PostgreSQL then you can use \d instead. I'm sure the other RDBMSes have their own equivalent (except for maybe SQLite but if you're using SQLite outside of toy environments or hobby projects, you're doing it wrong).

This may be true, but you've missed the point that this is about aiding autocompletion while you're writing the query the first time.

Couldn’t the IDEA understand

FROM table SELECT

And when done switch the code to be correct?

Re: A Critique of SQL, 40 Years Later

#200

Post by xpe »

gibsonf1 wrote: post #17

I think the issue isn't SQL, but the table paradigm for storing data. Humans do not store data in separate tables that need joining, they store data in a fully connected graph (hyper-graph). Its about relationships and hierarchies - the graph allows incredibly fast hierarchical reasoning, as most things involve hierarchical reasoning. The relational table, and Sql by correlation, are terrible at the human approach to…

Do you think computers should try to store data like humans? Why?

Perhaps you don't mean storage but rather a conceptual model?

Post reply on HN