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

151–160 of 304 posts

Re: I don't need your query language

#151

Post by iLoveOncall »

daxvena wrote: post #135
iLoveOncall wrote: post #38

Earlier quoted context omitted.

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.

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 is still position" was not connected to the first part of my comment.

Re: I don't need your query language

#152

Post by bokwoon »

ayhanfuat wrote: post #2

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

https://twitter.com/edgedatabase/status/1620582614703964160

EdgeQL:

    select Child {name}
    filter .
SQL:

    select child.name
    from child
    join parent_child_rel using (child_id)
    join parent using (parent_id)
    where parent.name = 'Uma Thurman';
IMO EdgeQL is going too far with the sigils

Re: I don't need your query language

#153

Post by tomnipotent »

littlestymaar wrote: post #147
tomnipotent wrote: post #95

Earlier quoted context omitted.

> which costs CPU Which costs very little CPU in 2023. > deserialised on the application server This is true regardless. The low-level libraries are still parsing the stream into meaningful in-memory structures. With JSON, the low-level library only has to parse a variable length string, then JSON decode. I'm unfamiliar with any language in 2023 that doesn't have incredibly fast and efficient JSON parsers. > bandwidt…

> Which costs very little CPU in 2023. That's a very bad argument for an RDBMS, since you want to make it scale vertically as much as you can (unlike your application server, horizontally scaling your database is a completely different matter, and isn't straightforward at all).

The added cost of JSON serialization is easily offset by reducing the total number of overall queries and implicit (or explicit) transactions. The additional parallelization the RDBMS can achieve is generally greater than the added JSON serialization and extra network bandwidth.

Re: I don't need your query language

#155

Post by tomnipotent »

password4321 wrote: post #134
411111111111111 wrote: post #122

Earlier quoted context omitted.

The funnest part of outputting JSON from the query is that your API now basically becomes a RPC, as you don't have to do any marshalling/deserialization before returning the response with Content-Type application/json Response times are really fast like that, as you probably already know. Always fun to see Also no worry about n+1 queries, as they're fundamentally impossible to do like that

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…

You've basically described Firebase and its archetype of database.

Re: I don't need your query language

#156

Post by fbdab103 »

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.

I like PRQL [0]. It fixes a lot of the SQL warts and compiles down to regular SQL (think Typescript to JS).

The syntax example on the PRQL homepage

  from invoices
  filter invoice_date >= @1970-01-16
  derive [
    transaction_fees = 0.8,
    income = total - transaction_fees
  ]
  filter income > 1
  group customer_id (
    aggregate [
      average total,
      sum_income = sum income,
      ct = count,
    ]
  )
  sort [-sum_income]
  take 10
  join c=customers [==customer_id]
  derive name = f"{c.last_name}, {c.first_name}"
  select [
    c.customer_id, name, sum_income
  ]
Trailing commas, select at the bottom, filter is both a WHERE and HAVING replacement, easy filtering of created columns, etc

[0] https://prql-lang.org/

Re: I don't need your query language

#157

Post by Hendrikto »

Funny how differently things can be framed.

You can either call SQL proven and battle-tested, or crusty and outdated, depending on your agenda.

Same for the fancy new alternative: It is either fresh and innovative, freed from the shackles of legacy and standard-compliance, or reinventing the wheel in a non-standardized manner.

Re: I don't need your query language

#158

Post by zaxomi »

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.

If I could change one thing with sql, this would be it.

It makes more sense to have the select last.

Re: I don't need your query language

#159

Post by remram »

tomnipotent wrote: post #142
mattmanser wrote: post #131

Earlier quoted context omitted.

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.

> it's.objective. Prove it. > You're just clearly someone who can't admit when they're wrong You don't have a good technical argument so you jump to ad-hominem's?

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

Re: I don't need your query language

#160

Post by vlovich123 »

civilized wrote: post #51

It's funny how some devs are negative towards SQL but fiercely protective of other much more obscure tools from the 1970s, like unix utilities.

It’s more likely devs are a heterogenous group and you are mixing opinions from unrelated people? Unix utilities from the 1970s are shit. Many of their descendants today aren’t that bad but have lots of problems (eg gawk and gnu sed can do magic in the hands of masters but getting that proficiency is probably not worth the effort).

SQL is a problem not because of the era in which it was developed, but because somehow we haven’t evolved any meaningful successors. We have a bunch of dominant programming languages and only 1 data mining language? What’s up with that? Why is there this pretense around only having one language? Multiple languages are healthy because ideas cross-pollinate. How long after MongoDB did it take database vendors/OSS projects to start adding JSON support to their SQL databases?

Post reply on HN