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

Sq.io: jq for databases and more

sq.io

Post reply on HN
Print view View original

111–120 of 134 posts

Re: Sq.io: jq for databases and more

#111

Post by EGreg »

fforflo wrote: post #76
dewey wrote: post #48

Sometimes I wonder if it wouldn't be more efficient for people to just learn SQL instead of trying to build tools or layers on top of it that introduce more complexities and are harder to search for.

Paraphrasing Spencer: Those who don't understand SQL are doomed to reinvent it, poorly

Actually, when it comes to SQL specifically, it almost demands using a language one higher up.

Any language that features the ability to embed/interpolate unescaped quotes is not secure enough to be used directly by professional developers. Just not worth it to track down all the potential injection attacks.

And if an abstraction lets you understand the structure of queries (eg for sharding them) and even writes the code for you and balances parentheses, flags other syntax errors at compile time etc. then it’s a net benefit.

And of course there is the Adapter Pattern to abstract away connection logic and differences between mysql, pg, etc.

I wrote the “Db” library 12 years ago in PHP and still use it.

I never released it on HN for reasons like this. But I might. Here it is, embedded in my larger library, but I might break it out:

https://github.com/Qbix/Platform/tree/main/platform/classes/...

Documentation:

https://qbix.com/platform/guide/database

https://qbix.com/platform/guide/models

One of the coolest features:

https://qbix.com/platform/guide/models#relations

If you read the above, please let me know your feedback!

Question: Should I release it as a Show HN?

Re: Sq.io: jq for databases and more

#112

Post by simplify »

fforflo wrote: post #76
dewey wrote: post #48

Sometimes I wonder if it wouldn't be more efficient for people to just learn SQL instead of trying to build tools or layers on top of it that introduce more complexities and are harder to search for.

Paraphrasing Spencer: Those who don't understand SQL are doomed to reinvent it, poorly

SQL itself is a reinvention of Prolog, poorly. Its core value is that we're stuck with it.

Re: Sq.io: jq for databases and more

#113

Post by bazoom42 »

simplify wrote: post #112
fforflo wrote: post #76

Earlier quoted context omitted.

Paraphrasing Spencer: Those who don't understand SQL are doomed to reinvent it, poorly

SQL itself is a reinvention of Prolog, poorly. Its core value is that we're stuck with it.

SQL is based on relational algebra. Poorly some would argue.

Re: Sq.io: jq for databases and more

#114

Post by VMG »

pie_flavor wrote: post #86
VMG wrote: post #55

Earlier quoted context omitted.

Kind of. However on first glance it seems like the separator in PRQL is a newline instead of a `|`, which is less ergonomic in a shell.

Newline and pipe mean the same thing and are interchangeable.

nice - are there any PRQL CLI tools for json?

Re: Sq.io: jq for databases and more

#115

Post by deergomoo »

jeltz wrote: post #66
deergomoo wrote: post #64

Earlier quoted context omitted.

I agree with the GP’s point that people should probably just learn SQL, but there are things about SQL that are objectively bad, especially from the perspective of a software developer. It’s not a very composable or consistent language, so I think it makes total sense that we see so many abstractions over it.

The issue with the abstractions over SQL is that while they fix some problems they always introduce a bunch of new problems so in the end SQL is still preferable. I have yet to see an example where that is not the case.

For me query builders are the quintessential example. Not ORMs, just thin layers that allow you build up a query in pieces.

If you have cases where you might need to conditionally join, or have any reasonably complex filtering based on input, building up a plain SQL statement using string interpolation at the call site gets very messy very quickly.

Re: Sq.io: jq for databases and more

#116

Post by jeltz »

deergomoo wrote: post #115
jeltz wrote: post #66

Earlier quoted context omitted.

The issue with the abstractions over SQL is that while they fix some problems they always introduce a bunch of new problems so in the end SQL is still preferable. I have yet to see an example where that is not the case.

For me query builders are the quintessential example. Not ORMs, just thin layers that allow you build up a query in pieces. If you have cases where you might need to conditionally join, or have any reasonably complex filtering based on input, building up a plain SQL statement using string interpolation at the call site gets very messy very quickly.

I have used many query builders and experienced both the upsides and the painful downsides. The by far best one I have used has been JOOQ (Lukas Eder is a genius who really understands SQL well) but even that often causes more pain than it helps. Compared to the issues caused by them I in most cases prefer string interpolation of SQL.

Re: Sq.io: jq for databases and more

#117

Post by setr »

jeltz wrote: post #66
deergomoo wrote: post #64

Earlier quoted context omitted.

I agree with the GP’s point that people should probably just learn SQL, but there are things about SQL that are objectively bad, especially from the perspective of a software developer. It’s not a very composable or consistent language, so I think it makes total sense that we see so many abstractions over it.

The issue with the abstractions over SQL is that while they fix some problems they always introduce a bunch of new problems so in the end SQL is still preferable. I have yet to see an example where that is not the case.

The fundamental issue is that they have to generate SQL at the end of the day, so there’s a hard limit on how much you can really change. I don’t know why every database treats SQL as the only API, even Postgres. Even the extension systems, which have the opportunity to hook directly into DB internals (and has no standardization to bother meeting) end up with SQL as the API to do actual db operations.

Re: Sq.io: jq for databases and more

#118

Post by jeltz »

quotemstr wrote: post #109
dewey wrote: post #48

Sometimes I wonder if it wouldn't be more efficient for people to just learn SQL instead of trying to build tools or layers on top of it that introduce more complexities and are harder to search for.

Yeah. Alternatives to long-established and useful technologies have to meet a high bar before their option pays for their disruption. Things that seem potentially worth it to me: * seL4 * Google's SQL syntax tweak * Rust * GraalVM * systemd * Tree sitter * LSP * CMake * Bazel These all get you a step change improvement in comprehensibility, safety, or something else important. Things that seem like more churn than th…

While I agree with your general idea my lists are quite different.

I would move Zig (innovates a lot in language and compiler design) and JMAP (IMAP is horrible and needs to be replaced) up and CMake and Bazel down (I count them the same as Meson). I would say the jury is still out on Google's tweak and on seL4.

Re: Sq.io: jq for databases and more

#119

Post by raydev »

remon wrote: post #49
dewey wrote: post #48

Sometimes I wonder if it wouldn't be more efficient for people to just learn SQL instead of trying to build tools or layers on top of it that introduce more complexities and are harder to search for.

HN is inundated with posts announcing paper thin abstractions on top of existing technology or utilities that just move the goalpost of what you knowledge you need to be effective. It's a weird trend that seems almost entirely motivated by people wanting open source projects in their resume, or seek funding if its a startup.

Thankfully that doesn't apply to this post. sq is a great, full-featured tool.

Re: Sq.io: jq for databases and more

#120

Post by raydev »

dewey wrote: post #48

Sometimes I wonder if it wouldn't be more efficient for people to just learn SQL instead of trying to build tools or layers on top of it that introduce more complexities and are harder to search for.

Sometimes I wonder if it wouldn't be more efficient for people to just learn assembly instead of trying to build tools or layers on top of it that introduce more complexities and are harder to search for.
Post reply on HN