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

261–270 of 304 posts

Re: I don't need your query language

#261

Post by nurettin »

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…

You don't really need multiple result sets, you can do lateral joins (cross apply in microsoftish) to bring in any unrelated data and distinct the result. And fancyql doesn't provide any alternatives, so it makes no sense to even bring this up.

Re: I don't need your query language

#262

Post by paulddraper »

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)

But now you have to work in...shudder...JSON.

It's nice being able to use datetimes, 64 bit ints, binary, etc

Re: I don't need your query language

#263

Post by paulddraper »

rbalicki wrote: post #223
erikpukinskis wrote: post #215

Earlier quoted context omitted.

> 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) For anyone (like me) who is not quite able to visualize this, here is an example: SELECT json_agg(trips) FROM ( SELECT json_agg( json_build_object( 'recorded_at', created_at, 'latitude', latitude, 'longitude', longitude ) ) as trips FROM data_tracks GROUP by t…

As someone who would like to use SQL to return a tree-like structure, how well does this scale (in terms of readability, performance, etc.) when the query is extremely large and nested? For example, if we are attempting to replace GraphQL with some sort of SQL. I'm super unfamiliar with this space, and would love to know whether it is a feasible/worthy goal to replace GraphQL queries with generated SQL.

You might be interested in PostGraphile. [1]

[1] https://www.graphile.org/postgraphile/

Re: I don't need your query language

#264

Post by remram »

tomnipotent wrote: post #164
remram wrote: post #159

Earlier quoted context omitted.

They've presented plenty of drawbacks, which you've dismissed as "it's not that bad", while not presenting any benefit.

I've presented the bandwidth vs. memory and CPU trade-off, was that not obvious? Not to mention reduced network round trips, and less overhead on transaction management. If the biggest issue in my product is JSON deser, I'd be a happy camper.

Bandwidth and memory are probably both worse, JSON adds overhead. Round trip latency only happens if you wait for the results of one query to send the other.

Re: I don't need your query language

#265

Post by hosteur »

amai wrote: post #237
hosteur wrote: post #58

I would love if sql would support a slight syntax change of accepting From table select col; as an optional alternative to select col from table; This would allow autocompleting col names in editors. Other than that I quite like sql being the standard db query language.

Have a look at https://prql-lang.org/ . They got this right.

> Have a look at https://prql-lang.org/. They got this right.

Yes, they absolutely got this right. But I agree with the author of TFA in that I don't want another query language. I just want this specific change to SQL. Maybe others as well. But I do not want another query language. PRQL is yet another query language.

Re: I don't need your query language

#266

Post by baq »

rjbwork wrote: post #108
christophilus wrote: post #21

Earlier quoted context omitted.

LINQ and proper reflection are what I miss most from C#. (I’m all Typescript at the moment.)

Gods, I tried to do some reflection stuff in a Node TS project I got put on about 18-24 months ago, and it was a total shit show. It was really disappointing to see how lacking the actual runtime capabilities of TS are.

What runtime capabilities? There shouldn’t be any?

Re: I don't need your query language

#267

Post by jeltz »

tikhonj wrote: post #238

Having used (a lot) of Hive SQL, I absolutely do need your query language. SQL is fundamentally incapable of expressing any sort of abstraction, so non-trivial queries quickly become completely incomprehensible, unmaintainable and bug-prone. Learning a new language is a one-time, up-front cost. Dealing with an awkward, inexpressive query language that integrates poorly with my main language, my types or my interface…

Because the alternatives are worse. It is that simple.

Re: I don't need your query language

#269

Post by scottcodie »

galaxyLogic wrote: post #136

The problem with SQL is that it is not a (very) composable language. The documentation for EdgeDb goes into some detail about that and shows an alternative better language for data-queries. https://www.edgedb.com/showcase/edgeql To understand why SQL is bad, you must first be shown something better, and EdgeDb seems to be such better more composable language.

SQL in the context of a single query struggles with a composable features. But looking slightly outside the scope of queries with assignment statements and view/materialization dags then you start getting some of that composition back. I think SQRL is an good example of SQL with a bunch of composable feature bolt-ons.

https://www.datasqrl.com/blog/sqrl-high-level-data-language-...

Re: I don't need your query language

#270

Post by [deleted] »

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

> But if that's the case, why are declarative languages not more popular? Declarative programming is not very popular because it’s hard to debug. You can’t step through it and inspect intermediate representations. It presents a black box to the developer. That said, they do seem to show up around certain very complex APIs sometimes. Besides SQL, CSS is the obvious one. And I think many parts of otherwise functional/i…

[deleted]
Post reply on HN