I now regret using JSON as an example since everyone wants me to convert
SQL to JSON for them now, but my point isn't any particular notation, I
want an API of sorts instead of a notation or syntax. Then you can adapt
anything you like and make it efficient with the platform you're using. So
for example you send a native, binary JavaScript object (or record,
whatever its called) as your query instead of SQL text.
What is motivating this for me is that I generate many unique queries in my
code for almost any operation. Converting those to SQL is error prone and
uses a lot of memory compared to the operation involved. The database
engine is so fast and efficient yet I'm wasting resources making SQL!
I just want to skip that SQL bottleneck, because it has no technical
justification other than "standardization" and pass my query straight
through.
On Thu, Jun 4, 2015 at 3:13 PM, R.Smith <rsmith at rsweb.co.za> wrote:
>
>
> 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
>
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
