On 2015-06-05 12:11 AM, Darko Volaric wrote:
> Are you seriously saying that that SQL syntax is friendly? How can you
> defend SQL syntax other than on grounds of history or standardization? If
> you're more comfortable and familiar with JSON the yes it is easier and you
> can avoid an unnecessary conversion step.
And
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.
The defense of SQL is much like the Defense of the English language. It
isn't the best language out there, it is full of idiosyncrasies and
vestigial bits of long dead habits. It just happens to be the language
spoken by most people whom you wish to talk with. SQL is even better
than that - not only does it present a language understood by all
serious database engines, it is understood by people and even reads like
English. Some of it can be better I suppose, but that is down to preference.
I think you underestimate exactly how useful and efficient SQL is. It
can produce infinitely many and widely differing, yet algebraically
correct, data compilations from a very limited vocabulary. We are not
stubbornly clinging to the old and deprecated - we actually think the
way it works is quite neat.
That said, I get your point. You want to send the Query parameters in an
object or binary format because it's more like programming or OO than
SQL is, and safer.
The premise is wrong though. There is nothing intrinsically safer or
more efficient about compiling and sending bits from an object than bits
of text. The parser will parse it either way and produce an outcome. If
you think that you can suggest to the parser sufficiently via a binary
object to avoid a lot of parsing, then I have great news for you - you
can already do that by simply adjusting the properties of the *stmnt
object returned by sqlite3_prepareV2() in glorious bit-byte detail. An
attempt to do so will quickly prove that making the SQL and letting the
parser do its bit is by far the preferred method.
The second premise is also wrong - there is nothing about the properties
of an object that make them less prone to bugs/inefficiencies or human
error than an SQL string. (JAVA objects do not even have proper
templates, they are especially prone to error).
Also, the lifetime of any SQL-text bug is limited to the first time the
query is run. The only other thing I can think of might be that you do
not test queries before implementing them or they are created on the fly
by possibly a user process. In the latter case, any bugs there would
equally likely be propagated through an object or binary representation
of sorts.
To be clear of what I intended to say: You might prove to have something
useful still, and I'd be interested to see how it may work, but please
note that if SQL is a bottleneck, it's an extremely low-cost unobtrusive
one, and its only justification is NOT merely "standardization", not
more than the use of Liters as a measure of volume is merely tolerated
because it is standardized - it might not be particularly fantastic, but
happens to be no worse a measure of volume than any other, and until the
converse can be shown, it is likely to remain the standard.
