Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.databases Subject: Re: SQL Precompilers Message-ID: Date: 10 Aug 90 03:01:44 GMT References: <1990Jul26.141643.6361@dg-rtp.dg.com> <1990Aug8.145522.10694@dg-rtp.dg.com> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California. Lines: 82 In-reply-to: cohend@roadkill.rtp.dg.com's message of 8 Aug 90 14:55:22 GMT In article <1990Aug8.145522.10694@dg-rtp.dg.com> cohend@roadkill.rtp.dg.com (Dave Cohen) writes: In article , cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: |> |> Why would you want the embedded approach to SQL? Regardless of how well |> the precompiler is implemented, the support for it by other products will |> never be good. Consider how many utilities in Unix are screwed up with |> embedded SQL in a C program (for instance, FCREF, INDENT and VGRIND). |> In my book, the function call approach for sending SQL statements to the |> database is the correct one (ashame I haven't been given the chance to |> use it). It breaks far less utility routines that are very important to |> the programmer. Also, if you shift back and forth between languages |> (like C and C++), there is no new syntax to learn or tricks to apply |> (like faking an SQL precompiler for C to not mess up C++ code). Two important points here, David: 1) C to C++ is a trivial language switch. Howza bout Cobol to C? Function calls will change dramatically, embedded SQL will change very little. 2) There is an ANSI standard for embedded SQL. No such animal exists for function calls, implying no portability among vendors. First, I am not suggesting abandonment of ANSI-SQL (although there are plenty of reasons for that -- see Codd[90]), just embedded SQL. Functions can certainly take SQL as input. 1. SQL will change very little in either case. The support code around the SQL will change in both cases. Agreed, function calls may be a dramatic change when moving from environment to environment, but (I contend that) embedded SQL causes a more dramatic change in the use of one environment (for instance, the breaking of the UNIX support tools for C programming). Which is more important (how many environments do you use regularly)? 2. As has been seen, there is limited support for the ANSI-SQL standard. Almost everyone goes beyond the standard in some way (therefore, cutting direct portability). Also, the standard, itself, is limited in what it (currently) standardizes, so the vendors often have to go beyond the standard to handle their specifics (as I see from the Rdb/VMS manuals). Certainly, this will get better over time, but so could the standard of function call names, IF people desire it. |> I believe that the statement "precompiled applications run faster and are |> easier to code than call level SQL" may be true with what is often |> supplied, but is wrong as a general statement. In order to optimize a |> precompiled statement the way that is suggested, certain aspects of the |> SQL must be fixed for that statement (relations to deal with, columns |> within the relations, operators to be applied). This cuts out any |> dynamic SQL capability. A very good precompiler might determine the |> difference between a statement that will be treated dynamically and one |> that will not and, therefore, make appropriate optimizations. However, |> that is not always possible (for instance): |> |> SELECT col FROM table |> WHERE col = :var; |> |> A precompiler might make the assumption that everything is known and, |> therefore, optimizable, but what if the user chose to fill "var" in |> with "1 or col = 2" at run-time. It changes the whole complexion of |> the statement (especially from the optimizer's perspective). This can |> get far more complex, Are you saying that changing a variable's value will slow down a preoptimized statement more than the dynamic statement's costs for lexing and parsing ? This is absurd!!!! No!! I merely said that, if you make no assumptions about what a statement means, then it is very hard to preoptimize any SQL statements. However, thinking about SQL, I think my thought process in making the statements above was wrong which makes the statements unintelligible. Suffice it to say, there is nothing I see to suggest that a function call approach would be any different in performance than an embedded approach. Also, "more user friendly" to me is a caveat emptor -- we could start religious wars over statements like that. -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"