Embedded SQL, again
Date: Wed, 15 Nov 2006 20:55:40 GMT
Here's what I'd like better than embedded SQL in a programming language. Or so I think.
I'd like a programming language whose syntax and semantics comprises both the functionality of a good general purpose programming language, and a language at least as good as SQL for carrying out the DML functions of transactions with a database.
So it should have something like SELECT, INSERT, DELETE, and UPDATE, or at least cover the same ground.
I'd like a single compiler that processes the entire program I've written, and translates it into a form suitable for execution on at least two machines: the target excution computer, and the DBMS server. I don't really care whether the compiler's output, the object code, is written for a virtual machine, like the JVM, or for an actual machine, like an intel processor, or a compibantion of the above with OS service calls. The object code would, of course, have to be able to interleave the JVM (or whatever) code with DBMS executable code.
This DBMS executable code need not look like SQL. It could be expressed as binary numberger as far as I'm concerned, as long as its semantics are powerful enough to express what needs to be expressed.
Here's how I want it to be better than embedded SQL:
First, I want practically transparent data transfer between host language variables and database "variables" if I can call them that.
Second, I want it to deal with relational tables rather than SQL tables.
Here's where I'm willing to make sacrifices: I'm willing to forego dynamic query generation at runtime, except that I'd like to be able to speak through a dynamic intermediary when necessary. I'd like optimization to take place at runtime, rather than compile time, with suitable hooks for avoiding redundant optimizations of the same query. I'm willng to forego DDL from the programming language.
I know nothing about the language "D", but I expect it has dealt with at least some of these issues. Received on Wed Nov 15 2006 - 21:55:40 CET