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 >