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

I don't need your query language

antonz.org

Post reply on HN
Print view View original

191–200 of 304 posts

Re: I don't need your query language

#191

Post by Kamq »

PhilipRoman wrote: post #71
Olreich wrote: post #40

Earlier quoted context omitted.

`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 t…

I think these two concepts could be reconciled by having selection be combined with moving. So 3w could select three words but also move the cursor to the end of selection, ready to process another normal mode command. The highlighting would need to be scaled back a little (perhaps a dark gray background), as you don't want your entire screen to light up when moving but I think it's doable.

> So 3w could select three words but also move the cursor to the end of selection

I mean, if you hit v first, that's exactly what it does.

Re: I don't need your query language

#192

Post by weinzierl »

jmull wrote: post #113
idoubtit wrote: post #88

Earlier quoted context omitted.

> Usually start with "select * from table limit 10", look at the columns and data available, and then start refining. An experienced person won't do that. For any moderately complex SQL query, before writing it I already have in mind the several jointures I'll need, since I usually know the tables and FK I'm working with. It's like following the edges of a graph, all in my head. But I don't know all the fields of the…

> An experienced person won't do that. I’m very experienced and do that kind of thing all the time. Also, your “SELECT 1” technique seems like practically the same thing, except I guess you discover column names from autocomplete tooling rather than query output. (To my mind the difference is inconsequential.)

Me too and I don't even bother with LIMIT 10. However, the "proper" experienced way would be DESCRIBE I guess.

Re: I don't need your query language

#193

Post by tlarkworthy »

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…

I keep staring at the output of sqlalchemy's "select in" eager loader trying to figure out if has managed to pipline the follow up queries into a single DB round trip for the problem of tree shaped data. Still don't know, maybe someone does.

https://docs.sqlalchemy.org/en/14/orm/loading_relationships....

Re: I don't need your query language

#195

Post by mborch »

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

This is no longer true in database that have JSON support (which is most of them these days). You can aggregate the result of a subselect into a single column (the underling data doesn’t have to be stored as JSON, you can convert as part of the query)

JSON has pretty limited choice of data types though. Want better precision for numbers, use a string. Want dates? Use a string. Etc.

Re: I don't need your query language

#196

Post by llimllib »

divan wrote: post #176
divan wrote: post #175

FancyQL, which he mentions, is, of course, EdgeQL – an insanely good query language of EdgeDB. The truth is EdgeQL is so good that you never want to go back to SQL ever after. It's even a bit depressing when you realize how much time has been spent crafting SQL queries and dancing around it. EdgeQL renders most of those struggles obsolete. The author of this post has written a book about SQL Window Functions, and pro…

Shameless plug – I wrote a post with my experiences with EdgeDB last year. It's a bit outdated already, EdgeDB 3.0 launch is happening next week, but I can only add good things to the post so far. My experience with EdgeDB (Jul 26, 2022) https://divan.dev/posts/edgedb/

> So if you’re a hardcore SQL user proud of their 20+ years of SQL experience – don’t try EdgeQL. It’s always hard to downgrade your identity from “master in something overly-complicated” to “newbie in better-and-less-complicated”.

My eyes rolled so hard they actually flipped completely around

Re: I don't need your query language

#197

Post by thomasmg »

We write programs with Python, Java, Rust, Javascript and so on. Yet we use a very different language, eg. SQL, to query and modify data. Why? Why don't we use eg. Python as well? SQL is different from other languages: it is declarative, meaning it doesn't dictate how to do it, but what the response should be. Maybe that's the reason? But if that's the case, why are declarative languages not more popular? SQL and other language are not compatible, and that's often a problem. You have this hard border (related to impedance mismatch).

SQL (or GraphQL) is often used as a remote API: The client sends a SQL statement, the server processes it and sends the response. SQL is very powerful, but also dangerous: the statement might be very expensive, for example because an index is missing. Sure, you can shoot yourself in the foot also with Python or Java, but I argue it's harder. SQL is one more technology in your stack, one more thing to learn. And actually, there are many many SQL dialects.

I wish databases have better, faster, and standardized support for a fast procedural language. So that clients can send programs, the server processes it and sends the response. A way to access tables and indexes like a hash table or ordered map. That way, there is no border. There is no slow query due to a missing index. You have to think about how data is access, which indexes are needed. But you have everything under your control. There is no risk of a missing index, or risk of the database not picking the index it should.

(I wrote 3 relational database engines and 4 SQL parsers: HypersonicSQL, H2 database, Apache Jackrabbit Oak, PointBase Micro. I also wrote a GraphQL parser and engine, and a Key-Value store. It's not that I hate SQL.)

Re: I don't need your query language

#198

Post by ako »

idoubtit wrote: post #88
ako wrote: post #16

Earlier quoted context omitted.

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.

> Usually start with "select * from table limit 10", look at the columns and data available, and then start refining. An experienced person won't do that. For any moderately complex SQL query, before writing it I already have in mind the several jointures I'll need, since I usually know the tables and FK I'm working with. It's like following the edges of a graph, all in my head. But I don't know all the fields of the…

I consider myself experienced, started professionally with sql in 1994 with oracle 6, and it really depends on how familiar you are with the database. I often work with databases I’m not familiar with, so exploring the structure by looking at examples of the data is where I start.

Re: I don't need your query language

#199

Post by ako »

thomasmg wrote: post #197

We write programs with Python, Java, Rust, Javascript and so on. Yet we use a very different language, eg. SQL, to query and modify data. Why? Why don't we use eg. Python as well? SQL is different from other languages: it is declarative, meaning it doesn't dictate how to do it, but what the response should be. Maybe that's the reason? But if that's the case, why are declarative languages not more popular? SQL and oth…

The problem with procedural is that it doesn’t optimize very well. The fastest way to get your data for a large number of random queries often depends on the data size, the available indexes, but is also influenced by changes in data size, etc. What is fast for a small dataset might be slow for a larger dataset. The right algorithm also depends on your filters and caching.

It’s almost impossible to write procedural queries that always perform, that is a really hard task. That’s why we use a declarative query language, I tell the database what data I need, and the database optimizer will determine the best performing algorithm to fetch the data based on all dynamic statistics it has.

Don’t underestimate how much hard work the database optimizer takes care of, I’m glad I don’t have to program all of that myself.

Better get used to this way of working, it resembles pretty much how AI assists us.

Re: I don't need your query language

#200

Post by forgetfreeman »

sp33der89 wrote: post #85
nickpeterson wrote: post #72

Earlier quoted context omitted.

I tell new developers that SQL is one of those few things in our field you get to keep forever. That JavaScript framework that takes a year to understand will no longer be used in 7 years. SQL is going to be here forever and learning it is useful your whole career. Other common entries on this list of forever tools: regular expressions, emacs, bash/shell scripting, excel, probably more I’m forgetting. Devs always pus…

> that JavaScript framework that takes a year to understand will no longer be used in 7 years. Surely there is a lot more nuance for having a nicer database query language than comparing it to JS frontend practices. SQL is something that'll stick for a long time, but I support attempts from people that don't want to let SQL be the endgame. Of course don't go around deploying highly experimental shiny things on produc…

Nuance? Not really. Bullshit flash in the pan tech stacks are what they are regardless of how much marketing drapery one adorns them with.
Post reply on HN