This is the same technique that Looker uses for all DBs, not just the ones that don't support CTEs.

Unfortunately, it trades what would be 2 O(N) operations for one O(N^2) operation, which is an unfortunate trade-off.

Additionally, I have found it extremely difficult to debug or tune queries written like this.

Expand full comment

Somewhat tangential, but I'm curious how much you have explored Graph databases and Cypher as an alternative to SQL as well? (https://neo4j.com/docs/getting-started/current/cypher-intro/)

I've personally be interested in it for some time, but Cypher as a query language is such a pain to write that I've never really invested much time into it.

It *seems* like Malloy might be trying to solve a somewhat similar pain point in that it's reducing the duplication when querying data.

Perhaps they're not exactly comparable since graph databases are a completely different type of database, whereas Malloy is interacting with relational DBs in a different way than SQL. But was still curious if you explored Graph DBs & Cypher and had any opinions on it.

Expand full comment

Very interesting. I could see a lot of value here. How do you handle the various dialects?

Expand full comment