Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

SQL really sucks. In general I'm not a fan of SQL-like syntax since it makes queries with lots of joins really difficult to read -- it's hard to keep track which value came from where.

GraphQL has some neat ideas and I really love the clarity the nesting provides. But GraphQL is also too limiting: it can't express arbitrary filters, recursion, optional edges (i.e. left joins), etc.

My own take on this is an embeddable GraphQL-like language with all those features and with strong guarantees about execution performance. I've been calling it Trustfall, and you can play around with it (or check out example queries over HN data) in your browser here: https://play.predr.ag/

For example, here's the query "Find the GitHub or Twitter accounts listed in the bios of HN users that comment on HN stories pointing to Open AI's website": https://play.predr.ag/hackernews#?f=1&q=IyBDcm9zcyBBUEkgcXVl...

The repo is here: https://github.com/obi1kenobi/trustfall

It's not just a toy implementation -- it has real-world uses too:

- I gave a conference talk on how to use Trustfall to query any kind(s) of data sources, from APIs to DBs to raw files: https://www.hytradboi.com/2022/how-to-query-almost-everythin...

- cargo-semver-checks, a semver linter for Rust crates, uses Trustfall to define its lint rules: https://github.com/obi1kenobi/cargo-semver-checks



I think you should try Datalog, or a flavour of it called Cozo: https://docs.cozodb.org/en/latest/

Disclaimer: I wrote Cozo.


>it's hard to keep track which value came from where

Isn't that dependent on how you write the query? If you put the table name or it's alias before the column it's quite easy to keep track of the data source.


Try it with a query that has 40 joins with multiple joins to the same table from different places, and let me know if you still think it's easy :)

At work I've seen SQL queries that are thousands of lines long that would make that 40-join query look like a toy example.


That's what I always tell people advocating for plastic straws. They think plastic straws are great, they drink their cocktails with them and everything.

Then I tell them how when I try to wash my cars by assembling 50 straws into a water hose, the whole plastic straw concept quickly breaks down.

In my opinion you should never use plastic straws.


Best not to have a single query, but to break it down into a number of separate views and join those views for your final query.


That's exactly what I do and why aliases exist.

It's manual effort, but that's documentation always.


I mean, they're also talking about using the same table multiple times - aliases aren't just useful, they're required in that case so the engine knows which one you mean when using a column from one of them.

Best guess without actually seeing these queries, whoever wrote them is using bad aliases (like "foo1", "foo2" and so on) instead of something more reasonable.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: