Re: approaches for embedding a data language in a general purpose language
Date: Wed, 18 Oct 2006 10:53:52 GMT
Message-ID: <4JnZg.4749$5v5.1737_at_trndny08>
"Frank Hamersley" <terabitemightbe_at_bigpond.com> wrote in message
news:L00Xg.45334$rP1.44072_at_news-server.bigpond.net.au...
> Aloha Kakuikanu wrote:
> > Marshall wrote:
> >> Anyone have any opinions, pro or con, about embedded SQL?
> >
> > OK, compare
> >
> > #sql { INSERT
> > INTO person
> > VALUES ('999999999', 'Doug Barry');
> > };
> >
> > with
> >
> > Statement stmt = conn.createStatement();
> > stmt.execute("INSERT
> > INTO person
> > VALUES ('999999999', 'Doug Barry')");
> >
> > Do you see much difference? I don't.
>
> or if tersely expressed ...
>
> #SQL INS person &Value1 &Value2 #
>
> Pro - allows a parser to translate from the generic form to any vendor
> dialect automagically, but
>
> Con - encourages developers to fragment business logic throughout the
> various system layers rather than my preference of keeping as much as
> possible as deep as possible. ie. stored procs over embedded dynamic
> assembly if possible.
>
> Cheers, Frank.
PMFJI. I began responding to Marshall in this thread, but dropped it, and it's scrolled off my view since then.
Frank,
The "static SQL" versus "Dynamic SQL" carries a lot of implications. In
Rdb/VMS where you can do either one, I found that some programmers who were
attracted to dynamic SQL liked it because they really needed to defer query
construction until runtime. These people were building expert systems that
used an AI style of code building to ask questions of a database that were
hitherto unimagined.
More frequently, they were simply journeymen programmers who didn't want to
think things out in advance.
There are some advantages to static SQL, but you pay the price for earlier
binding.
Marshall,
Here are some of the topics I wanted to get into with you with regard to "embedded DML":
The tight linkage between Pascal and RDML in the early Rdb pascal precompiler. (RDML preceeded SQL as an interface language for Rdb). This contrasts with the loose linkage I've seen in precompilers for SQL, and in the DEC precompilers for COBOL, Basic, and FORTRAN even before SQL. A loose linkage precompiler isn't really parsing the host language. It's only "compiling" the SQL into something else.
A little language called SQLMOD in DEC Rdb. It allowed essentially the same capability that stored procedure do, except that the implementation is quite different. The SQLMOD compiler (note that I didn't say precompiler) took the procedures and created an object module that could be linked with native code in any VAX language. The native code would contain calls to external procedures implemented in SQLMOD.
What advantage does this have over stored procedures? Well, an SQLMOD library could be built by programmers, without the necessity of altering the metadata in the database at all. Thus the database could remain quite stable over time, while the SQLMOD libraries could evolve as needed. This was especially valuable in an environment where the DBA isn't particularly responsive to the changing needs of the programmers, but instead focusses on managing data and data definitions. I've been in both roles, and I have more to say on this. Received on Wed Oct 18 2006 - 12:53:52 CEST