Re: The IDS, the EDS and the DBMS
Date: Sat, 11 Sep 2004 07:38:31 -0400
Message-ID: <acOdndc4UI9Bft_cRVn-hw_at_comcast.com>
"Marshall Spight" <mspight_at_dnai.com> wrote in message
news:0Zw0d.24024$D%.19457_at_attbi_s51...
> Ah, but while I applaud the desire to avoid joining camps,
You can make a choice without joining a camp. That's what I'm going to do
> you cannot escape the choice; it is with you everywhere
> you go.
> This issue is somewhat made obscure by the poor quality
> of linkage we have today between the type systems of
> our embedded data access languages and our application
> languages. If we design an architecture where the tyo
> type systems cannot communicate at compile, then
> we have implicitly chosen dynamic checking. (jdbc,
> odbc.) But wouldn't you really like it if the command
> you embed in a jdbc execute() statement could be
> checked *at compile time* for correctness?
Hold it!
What you say is true of dynamic SQL, of necessity. It's also true of SQL that's merely carted around as text until run time, because of lazy implementation.
But it is decidedly NOT true of embedded SQL that is processed by precompilers.
The precompiler connects to the database at compile time, and picks up the
datatypes of all the data exchanged.
It then expresses those datatypes in the native mode of the programming
language that the precompiler outputs to.
By the time the compiler sees the stuff, the original SQL is merely commentary. All the datatype conversion has been done.
A precompiler is harder to write than an ODBC driver, just as a compiler is harder to write than an interpreter. Received on Sat Sep 11 2004 - 13:38:31 CEST