|
|
|
|
|
|
by joe-user
990 days ago
|
|
|
Joins can certainly work in a data format like YAML. For an example, see Honey SQL from the Clojure community [0] (though without something to contrast strings like Clojure's keywords, you miss out on the automatic parameterization). You mentioned moving JOINs around, so I'll mention that if represented as structured data, you can move any of the top level components around, so you could more closely follow the "true order of SQL" [1]. For example, I would love to be able to put FROM before SELECT in all or almost all cases. There's also being able to share and add to something like a complicated WHERE clause, where essentially all programming languages have built-in facilities for robustly manipulating ordered and associative data compared to string manipulation, which is not well-suited for the task. Now don't get me wrong, I don't particularly care for YAML (though it doesn't bother me that much), but as someone who's done their fair share of programmatic SQL creation and manipulation in strings, not having a native way to represent SQL as data is a mistake in my opinion. 0: https://github.com/seancorfield/honeysql#big-complicated-exa...
1: https://blog.jooq.org/a-beginners-guide-to-the-true-order-of... |
|
|
What I was referring to is that 'SELECT * FROM A JOIN B ON f(A) = g(B)' and 'SELECT * FROM B JOIN A ON f(A) = g(B)' mean exactly the same thing, but this is not obvious from the language. This is especially iffy when you start joining even more tables together.
The equivalence is clear when you write out the corresponding diagram and note that the join is its limit, but your examples seem to make the same mistake SQL did by lumping together the join condition with one of the two tables.