Re: The IDS, the EDS and the DBMS

"Laconic2" <laconic2_at_comcast.net> wrote in message news: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 cannot escape the choice; it is with you everywhere
> > you go.
>
> You can make a choice without joining a camp. That's what I'm going to do
> on the first Tuesday in November.

Fair enough!

> > 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.

Just so.

It makes me sad that we often find a statically typed language, such as Java, embedding a statically typeable language such as SQL, using an interface that throws away all static information, such as JDBC.

Marshall Received on Sat Sep 11 2004 - 18:29:19 CEST