Re: S.O.D.A. database Query API - call for comments

[Lee Fesperman]
>> Hmm, there some real advantages to queries in string form:  

>> + easy to build using standard facilities

[Carl Rosenberger]
> No.
> [ ... cutted away a lot of reasons why SQL statements stinks ... ]

I agree with both of you. Letting a program build SQL statements is a hard and dirty thing to do - been there, done that several times.

Having the queries in a string form, at the other hand, might be a very smart thing. Of course, bit compiled code is always more efficient, both for storing and communication between clients. Look a bit around, there is not much things we use the computers for today that couldn't be done with fifteen years old technology - still the end user needs a state-of-the-art computer to pay the electricity bills and read the local news! It's outrageous - and one of the reasons is probably that most of the application protocols in the TCP/IP-world is in plain text, readable by human [programmers].

In the eighties and even early nineties I really thought that sending or storing data in human readable format was a silly idea. What a waste i.e. writing numbers as a decimal stringi - it's wasting bandwidth, and it's wasting CPU usage. Nobody would even consider such a thing as a Y2K-problem if dates and timestamps hadn't been written as human-readable strings.

Still, I've started realizing that it's quite smart to use protocols that can be accessed as human readable text. It simply makes debugging and data processing so much easier! And data conversion! I've always considered the FidoNet standards for file, mail ("NetMail") and news ("EchoMail") exchange as superior to TCP/IP, FTP, HTTP, SMTP, POP3, NNTP, etc. So why have "Internet" taken so much over? The priciple is; Keep It Simple Stupid.

Anyway, there really should be done some compression, optimalization and eventually encryption/authentication at some level. My suggestion, in general, is to first make human readable protocols, and after that optimize it by using binary data, compression, encryption, etc.

>> + usually the most compact form for network transport

Agreed, binary data - and particularly compressed/optimized binary data - is always more efficient and compact than text, and even gzip'ed text.

>> + portable to multiple DBMSs

As you say, The SQL implementation differs quite a bit, the standards don't include the necessary features. Anyway, textual representation usually offers better portability. Because textual formats often are considered easier to deal with, more software is written conforming to standards dealing with human readable text. The programmers don't have to think about byte order. Etc.

>> + human readable.

It is really possible to make incomprehensive SQL statements. SQL is no good standard. But it's far easier to debug SQL statements than other binary query languages.

[From the original post]
(...)
> - String queries do not have to be parsed by database engines.
> Advantages:
> - improved performance
> - reduced overhead and less resource consumption

As far as I know, most good RDBMS'es have possibility for parsing each SQL statement once, and then reuse the statement multiple times with different placeholders to avoid overhead and resource consumption.

If the SQL language had been more advanced, it should be possible to avoid all automatic generation of text queries. The programmer should complete all the SQL statements with the appropriate placeholders. I think this is the original idea. Unfortunately, as anyone programming a lot towards SQL databases have experienced, this is seldom true.

Probably an object oriented database approach is better suited. Maybe it can be a good idea to exchange objects methods in the Java language - I guess Java is the only language where binary code can be executed across different platforms.

[comp.lang.java.programmer cutted away from the follow up]

-- 
Tobias Brox, freelance hacker for hire.
Good at solving problems.
+47 98660706 / tobiasb_at_suptra.org