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

251–260 of 304 posts

Re: I don't need your query language

#251

Post by rwiggins »

I agree with the premise of the article, I think, but I find the "good SQL" versions... uncompelling.

(1) Switching `left join` to the default inner `join` changes query behavior. I'm guessing it's intentional on the author's part? But it feels like the wrong change to make when trying to compare syntax like-for-like.

(2) I am also in camp "SQL keywords really don't need to be uppercase", so keep fighting the good fight, brother. That said: it's an uphill battle and far from universal. Most SQL "formatters" I've used automatically uppercase everything.

(3) Dropping the alias in `Actors.name AS actor_name` is another case where you're not doing like-for-like. Just using `Actors.name` means, for example, the first example's output table will have two columns: title and name. I'd argue for most uses title and actor_name are better output column names.

Those points aside, the primary simplification seems to be switching `join ... on` to `join ... using`. Big +1 from me on that.

Re: I don't need your query language

#252

Post by YeGoblynQueenne »

nickpeterson wrote: post #72
jrumbut wrote: post #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 (unl…

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…

>> Other common entries on this list of forever tools: regular expressions, emacs, bash/shell scripting, excel, probably more I’m forgetting.

Oh yes, many more: Java, JCL & COBOL, Windows Forms, PhP, Wordpress, Joomla, Drupal, Perl, Visual Basic, IIS, SSIS, Ruby on Rails, and so on and so forth.

Maintaining enterprise software is a special circle of hell reserved for developers. Just sayin'.

Re: I don't need your query language

#253

Post by jrm4 »

I feel like this entire debate is strongly influenced, if not soon made obsolete and pointless, by the presence of the so called AI tools.

Feels like there's a universe of difference between the experience of "carefully craft the query yourself" and "describe the query and let AI write the code for it."

Re: I don't need your query language

#254

Post by riku_iki »

yencabulator wrote: post #189
nicoburns wrote: post #43

Earlier quoted context omitted.

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)

The crap mini-language of Postgres functions to manipulate JSON makes otherwise reasonable queries unreadable, though.

I think they are adding many readable function versions lately

Re: I don't need your query language

#255

Post by zapov »

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…

Those are problems in MS Sql, certainly not in object relational DBs such as Postgres or Oracle. And its rather sad that instead of embracing that we ended up with Json as poor man replacement for such advanced usages. I guess non portability across DBs certainly doesnt help. I tried showing that 10 years ago: https://github.com/ngs-doo/revenj/ but it just resulted in confusion.

Re: I don't need your query language

#256

Post by Reitet00 »

DaiPlusPlus wrote: post #20
tester756 wrote: post #9

Earlier quoted context omitted.

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 `.ToLi…

I wonder if that could be addressed at the spec level allowing reverse order of these keywords. It doesn't seem complex on the surface and the the engines could slowly add support for it.

Re: I don't need your query language

#257

Post by Jochim »

DaiPlusPlus wrote: post #230
recursive wrote: post #212

Earlier quoted context omitted.

It was all in memory. To the extent that it's a performance tradeoff, it might be one that's worth making depending on the use.

Aye - but the annoying thing is that it was never necessary: with a few subtle changes to Linq it’s possible to have allocation-free closures by passing state via hidden parameters on the stack - but just like every language out there we’re now hobbled by decisions made 15 years in the past. —— On a related note, it’s interesting just how unpopular so many new C# language features are (just by looking at the numbers…

I'm not sure the Github issues are the best reflection of the popularity of those features.

Top level statements and the new HostBuilders are fantastic, they're much cleaner and easier to follow than the previous mess. Add Minimal APIs to the mix and C# is finally a viable choice for spinning up something quickly.

Re: I don't need your query language

#258

Post by xupybd »

mattmanser wrote: post #131
tomnipotent wrote: post #111

Earlier quoted context omitted.

> you can't use 'negigibly' worse as a defence Absolutely you can when the increase in something (bandwidth) in a system with surplus supply with the trade-off of optimizing a more constrained supply (CPU or memory). > made a crazy SQL select instead of a normal one, which is harder to maintain. Purely subjective. Myself nor the people I've hired would have a problem maintaining a more complex SQL query using CTE's a…

It's not subjective, it's.objective. This solution for tuples is objectively worse in every way, throughout, network bandwidth, code complexity, maintainability, error likeliness. You're just clearly someone who can't admit when they're wrong.

>You're just clearly someone who can't admit when they're wrong.

I suggest avoiding statements like this. Yes they help vent your frustrations but they destroy the otherwise constructive and interesting debate the two of you were having.

Re: I don't need your query language

#259

Post by 411111111111111 »

vbezhenar wrote: post #168
password4321 wrote: post #134

Earlier quoted context omitted.

I've long wondered if there would be any performance advantage for an API server to zero-copy the DB response to the browser, deserializing from the DB wire protocol on the front end. Or perhaps sending DB query results directly from DB server to browser, with the API server just initializing and securing. Thanks for pointing out how JSON from the DB is another option for moving a bit of processing elsewhere in the s…

TLS everywhere makes the whole point of zero copying obsolete. Encryption eats so much CPU that copying data around does not change anything.

It does add a few ms, but you're overstating it. For LAN traffic, it's usually 5-8ms last time I checked on my servers.

Re: I don't need your query language

#260

Post by xboxnolifes »

iLoveOncall wrote: post #151
daxvena wrote: post #135

Earlier quoted context omitted.

I think you're missing what they're trying to say. You can still select what you actually need in a different order, but changing the order gives more immediate feedback from autocomplete. The order has pretty much zero impact on the performance of a query. A parser would still have to read out the whole query, and it's not expensive to unravel into a more efficient implementation if it would really help. The problem…

You are missing what I said. I know that from the interpreter's standpoint, it doesn't matter which one is written first. What I meant is that as a human, if you have to think first of the columns you want to bring in, it will guide you towards the joins that you need and only those, rather than thinking "let me join all those tables because I need _some_ data from the entities inside". My point about "autocompletion…

Even if I know the exact query I want to write, your suggestion does nothing to improve autocomplete for typing it in.
Post reply on HN