On 2015-06-04 11:16 PM, Darko Volaric wrote:
> My point about JSON, etc is that there is no reason not to use that as a
> query language if that makes it easier. If your system is efficient with
> JSON, why not accept a query that is formatted as JSON? It's not
> semantically different to SQL syntax. Here's an example (with a roughly
> JSON notation):
>
> {
> operation: "insert"
> table: "blah"
> columns: ["a", "b", "c"]
> values: [1.3, 2.0, 3.1]
> on-conflict: "replace"
> }
It's an interesting idea and I for one am willing to entertain the
thought, but I'm having difficulty seeing the "simpler" and "easier"
things you claim, or the memory saving for that matter.
Just take the above JSON query and consider that in SQL that would
simply look like:
REPLACE INTO blah (a,b,c) VALUES (1.3, 2.0, 3.1);
If we have to open a pole on which version seems simpler or use less
memory, the result would probably be indecisive if not plainly favouring
the latter.
I am willing to learn though, for instance, how do you see this next
query represented in the JSON way?:
INSERT INTO blah (1,b,c) VALUES
(1.1, 2.2, 3.3),
(3.1, 3.2, 3.4),
(5.1, 4.2, 3.5),
(7.1, 5.2, 3.6);
Or maybe this one:
SELECT MAX(A.Code), MAX(A.Name), B.Age, MAX(B.LastEditedDate) AS LastDT
FROM CodeNames AS A
LEFT JOIN Codehist AS B ON A.Code = B.Code AND B.Age > 30
WHERE A.Name LIKE 'SomeVal%'
GROUP BY B.Age
ORDER BY LastDT DESC
LIMIT 50;
(I'll forgo the "Having" clause for simplicity).
I'm finding it difficult to imagine a better layout for that query in a
JSON (or any other Markup-based) document - but I am quite willing (and
even interested) to be shown a way that makes more sense and satisfies
the claims of simplicity and memory efficiency.
Once a layout is found that works, I imagine it would be a whole other
can of spaghetti to make any program author the syntax sensibly, but
that is a worthy bridge to cross once the first question is answered well.
Alternatively, you might be able to show how the other notation might
ease the query-planner's work, or how it might help any other SQL
process work better or faster. Some significant improvement in
functionality or efficiency will make a much stronger case than "It's
easier to compose".
Ryan
