Daniel's concept is that of Embedded SQL, a marriage not quite made in heaven probably because of the clumsiness in integrating the database schema and the data definitions of legacy languages.

At one time we built a byte-coded implementation of a legacy language which did exactly as Daniel proposes, compiled the embedded SQL into the equivalent of the Sqlite VBDE and executed that at runtime. It realized the benefits Daniel predicts. The benefits were more evident back in an area of far slower machines than you would see today.

Christian Smith wrote:
Daniel Önnerby uttered:

Hi everyone!

I'm just a bit curios if it would be possible to make like a C precompiler or a macro of some kind that compiles/interpret the SQL-statements to bytecode just like the sqlite_prepare does but does this when compiling/precompiling your application instead of at runtime. Since most application written in C/C++ use static SQL-statements (unless you are building your SQL-strings on the fly) and then bind the values, I guess there would be several benefits for your compiled application:
* Faster: Since the SQL-statement is already interpreted.
* Smaller (not that sqlite needs to be smaller): The executable does not need to contain the part of sqlite that interprets the SQL-statements since this was made at compile time.




Run time compilation is not that expensive if the generated vm is cached. Just have a per-connection hash, use the SQL as the hash key, and the resulltingvm as the value. Upon first use, the SQL will not be in the hash, and will be compiled and inserted. Subsequent uses of the same SQL will be quickly retrieved from the hash and used as is.

This is how the TCL wrappers work, I believe.



Just a thought :)

Best regards
Daniel Önnerby


--
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
     X                           - AGAINST MS ATTACHMENTS
    / \

Reply via email to