[big_whack]

It's not really a problem of there being combinatorially many ways to join table A to table B, but rather that unless the join is fully-specified those ways will mostly produce different results. Your tool would need to sniff out these ambiguous cases and either fail or prompt the user to specify what they mean. In either case the user isn't saved from understanding joins.

[halfcat]

> ”but rather that unless the join is fully-specified those ways will mostly produce different results.”

As a SQL non-expert, I think this is why we are averse to joins, because it’s easy to end up with more rows in the result than you intended, and it’s not always clear how to verify you haven’t ended up in this scenario.

[sa46]

I wish there were a way to specify the expected join cardinality syntactically for 1:1 joins.

    SELECT * FROM order JOIN_ONE customer USING (customer_id)

Malloy has join_one: https://docs.malloydata.dev/documentation/language/join

[big_whack]

Sorry, but someone who is averse to joins is not a non-expert in SQL, they are a total novice. The answer is like any other programming language. You simply must learn the language fundamentals in order to use it.

[yunolearn]

To verify, you have to think through the problem and arrive at a solution, like all of programming.