Live data from Hacker News

I don't need your query language

antonz.org

11–20 of 304 posts

Re: I don't need your query language

#11
post #5

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

FROM users SELECT name, id, location WHERE name LIKE 'a%'; You know I think you're right.

Go further: `FROM users WHERE name LIKE 'a%' SELECT name, id, location` - after all, you can WHERE on things that aren't projected by SELECT

Re: I don't need your query language

#12
post #5

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

FROM users SELECT name, id, location WHERE name LIKE 'a%'; You know I think you're right.

There was an article on HN about this maybe 6 months ago. I’m in agreement.

Re: I don't need your query language

#13
post #7

Earlier quoted context omitted.

Ain't broke.

GP clearly shows why it is. I think SQL is great but their point is spot on.

The wrong order in the statements is a minor inconvenience but the widespread use and having an industry standard is 100x as valuable.

Re: I don't need your query language

#14
If this is about NoSQL databases, I dont think SQL is useful for databases which does not follow first normal form. But any alternative to SQL for relational databases will fight an uphill battle. While SQL is somewhat clunky, it is also deeply entrenched.

Re: I don't need your query language

#15
I think of SQL as one of the few good things we have in software development, so like the author I consider it best to try to do as much in SQL as possible.

It's not too uncommon I run into code in other languages where I just don't understand what it does, or to write code myself that behaves in ways that surprise me. That almost never happens in SQL.

Even a big hairball of a query just takes time to figure out (unless a database-specific function with odd behavior is used).

Re: I don't need your query language

#16

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

Always start with the end in mind, first what your goal is then how to achieve it.

Also, i don't actually see the problem because you never write a query in a lineair way. Usually start with "select * from table limit 10", look at the columns and data available, and then start refining. By now, code completion works as the table is known. Wouldn't help much to write it table first.

Re: I don't need your query language

#17
post #6

In case anyone is wondering he is talking about EdgeDB ( https://www.edgedb.com/ )

No. I'm talking about "SQL shaming" and about my preference for SQL over yet-another-query-language. I have absolutely nothing against EdgeDB or its creators. As far as I can tell, it's a great product.

All your example queries and quotations are from the EdgeDB landing page. Even if you are talking about "SQL shaming" you are very specifically talking about EdgeDB's SQL shaming.

Re: I don't need your query language

#18
SQL does have a significant drawback w.r.t. how databases are used today (imo): a SELECT query can only return a single resultset of uniform tuples: if you want to query a database for hetereogenous types with differing multiplicity (i.e. an object-graph) then you either have to use multiple SELECT queries for each object-class - or use JOINs which will result in the Cartesian Explosion problem[1] which also results in redundant output data due to the multiplicity mismatch - SQL JOINs also lack the ability to error-out early if the JOIN matches an unexpected number of rows.

And there are often problems when using multiple SELECT queries in a batched statement: you can't re-use existing CTE queries. Not all client libraries support multiple result-sets. It's essentially impossible to return metadata associated with a resultset (T-SQL and TDS doesn't even support named result sets...), which means you can't opportunistically skip or omit a SELECT query in a batch because your client reader won't know how to parse/interpret an out-of-order resultset, and most importantly: you need to be careful w.r.t. transactions otherwise you'll run into concurrency issues if data changes between SELECT queries in the same batch ()

[1] https://learn.microsoft.com/en-us/ef/core/performance/effici... and https://learn.microsoft.com/en-us/ef/core/querying/single-sp...

Re: I don't need your query language

#19

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

This is also my primary issue with vi.

d3w (`d`elete `3 w`ords) cannot be highlighted / indicated in any way ahead of time. If the motion specifier came first, it could be.

Re: I don't need your query language

#20

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

C#'s LINQ (query syntax, not methods) got it right var result = from s in stringList where s.Contains("Tutorials") select s;

or just `var result = stringList.Where( s => s.Contains("Tutorials") )`

I can't stand the non-extension-method Linq syntax: the _only_ place where it offers a readability improvement over ext-methods is using `join` - but I hardly ever do that in Linq anyway.

Also, in both my code and yours, `result` will be a lazy-evaluated `IEnumerable` which may be undesirable - which means it's probably a good idea to use `.ToList()` to materialize it - which means having to use ext-methods anyway - and mixing both syntaxes in the same expression is aesthetically atrocious.

Post reply on HN