Something that's easy to parse, and ideally adheres to the relational model. I'm not certain if the latter can be done in a performant manner, so I'd probably settle for a few compromises if they were well argued.
For example, a natural join between two tables could be represented as an S-expression:
(join a b)
The actual format is probably irrelevant. You could represent it as JSON or XML or some binary protocol. What would matter is that you were transferring a standard structure (i.e. a list consisting of 'join', 'a' and 'b').
Compare this to SQL where you'd actually send a raw string:
SELECT * FROM a NATURAL JOIN b
Although because SQL doesn't follow the relational model particularly closely, usually you'd write something more like:
SELECT * FROM a JOIN b ON a.id = b.a_id
Both of these statements are much harder to parse than a S-expression represented by some known format.
As well as being harder to parse, it's also harder to combine SQL. For example, perhaps I want to add a selection to limit the join:
(select (join a b) (= x 1))
Combining expressions in a S-expression is trivial, but in SQL it's more complex. You can't just wrap one expression in another - you'd want to extend an existing statement with a "WHERE":
SELECT * FROM a JOIN b ON a.id = b.a_id WHERE x = 1
More complex expressions become a mess of subqueries, and very hard to parse. Man ORMs actually represent queries as ASTs internally and only convert them into SQL at the last moment. If we could sent relational queries directly to the database we'd save a lot of work.
For example, a natural join between two tables could be represented as an S-expression:
The actual format is probably irrelevant. You could represent it as JSON or XML or some binary protocol. What would matter is that you were transferring a standard structure (i.e. a list consisting of 'join', 'a' and 'b').Compare this to SQL where you'd actually send a raw string:
Although because SQL doesn't follow the relational model particularly closely, usually you'd write something more like: Both of these statements are much harder to parse than a S-expression represented by some known format.As well as being harder to parse, it's also harder to combine SQL. For example, perhaps I want to add a selection to limit the join:
Combining expressions in a S-expression is trivial, but in SQL it's more complex. You can't just wrap one expression in another - you'd want to extend an existing statement with a "WHERE": More complex expressions become a mess of subqueries, and very hard to parse. Man ORMs actually represent queries as ASTs internally and only convert them into SQL at the last moment. If we could sent relational queries directly to the database we'd save a lot of work.