I don't need your query language • Hacker News Board

Re: I don't need your query language

#31

Post by LunicLynx » Sat, Jun 17, 2023, 11:30 AM UTC

ako wrote: post #16

LunicLynx wrote: post #4

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.

Exactly, you could actually drop the `select` in this case and just say `from table limit 10` don't state what you don't need.

What you describe is learned behavior to get along with a design flaw. SQL won't change, so no reason to worry.

My point is: People keep creating new versions of it, because it is not as `easy` to work with as it could be.

Re: I don't need your query language

#32

Post by quickthrower2 » Sat, Jun 17, 2023, 11:31 AM UTC

Why not both. If kibana supported sql that would be cool in addition to it’s 2 (or more) distinct syntaxes.

The issue is with non relational dbs like redshift that do support sql it is very easy to write an innocent query that takes hours to run if you don’t use specific keys in the query (ones used for sharding). But then some kind of warning or query plan indication would help there.

Re: I don't need your query language

#33

Post by wood_spirit » Sat, Jun 17, 2023, 11:31 AM UTC

LunicLynx wrote: post #4

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.

Yeap, simply supporting FROM … SELECT … WHERE … would make sql much more autocompleteable?

Re: I don't need your query language

#34

Post by 0x69420 » Sat, Jun 17, 2023, 11:32 AM UTC

people who intentionally choose sql databases often make every effort to avoid writing any of the stuff by hand, which should say something about how much of the value proposition lies in the language itself

> SQL has a solid standards committee that maintains and improves it.

so does c++. so does javascript. so does cobol

Re: I don't need your query language

#35

Post by turboponyy » Sat, Jun 17, 2023, 11:32 AM UTC

tester756 wrote: post #9

LunicLynx wrote: post #4

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;

The work was already done for them, as LINQ is just do-notation from Haskell.

Re: I don't need your query language

#36

Post by ellisv » Sat, Jun 17, 2023, 11:32 AM UTC

egeozcan wrote: post #3

Query language for database queries! I thought the argument were going to be against application query languages, like the JQL for Jira and so on, which I actually like.

Ugh I hate those. I’ve been using Jira for nearly a decade and have written numerous filters for dashboards, etc and I always have to look up the bespoke nuances of JQL.

Recently I was burned by a bad query in Google Log Explorer. There was no feedback my query was wrong, just no data.

Re: I don't need your query language

#37

Post by gozzoo » Sat, Jun 17, 2023, 11:33 AM UTC

DaiPlusPlus wrote: post #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…

Isn't your comment judging a fish by its ability to climb a tree?

Re: I don't need your query language

#38

Post by iLoveOncall » Sat, Jun 17, 2023, 11:34 AM UTC

LunicLynx wrote: post #4

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 a strength, not a weakness. It forces you to only select what you actually need, and state where it comes from afterwards, to only limit your query to exactly what you need.

This is paramount for performance.

If autocompletion is your issue, just get a better client, it's perfectly possible to autocomplete field names even before specifying database or table name.

Re: I don't need your query language

#39

Post by smitty1e » Sat, Jun 17, 2023, 11:34 AM UTC

nalgeon wrote: post #6

ayhanfuat wrote: post #2

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.

The joy of SQL is that it's so high-level.

Other responses note some (to me) esoteric enterprise use-cases for which SQL may not sufficiently describe exotic data vistas. Sure.

But most of the "shaming" one encounters seems to be about advertising some sort of magic wand product more than pointing out a substantial woe in a system that has been prominent for a half century.

Re: I don't need your query language

#40

Post by Olreich » Sat, Jun 17, 2023, 11:34 AM UTC

danielheath wrote: post #19

LunicLynx wrote: post #4

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.

`3w` is a command all its own. There’s an implicit move command baked in. Moving gets pretty clunky if you don’t have first order movement (adding a specifier or something to clear selection). You can mimic this by mapping a single button to and disabling all movement commands in normal mode. It’s rough, but may be learnable.

I think something that might work better is adding a “commit” signal to operations. So you type `d3w` and the editor highlights the next three words with a strike through or red or whatnot. Then you can hit enter to commit the delete or escape to cancel it (cursor resets to start position, highlight goes away).