Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!mtxinu!sybase!binky!tim
From: tim@binky.sybase.com (Tim Wood)
Newsgroups: comp.databases
Subject: Re: Parsing Query Languages in the Client or Server
Message-ID: <6291@sybase.sybase.com>
Date: 26 Sep 89 17:57:42 GMT
References: <6155@sybase.sybase.com> <17450@pasteur.Berkeley.EDU> <632@daitc.daitc.mil> <6253@sybase.sybase.com> <637@daitc.daitc.mil>
Sender: news@sybase.sybase.com
Reply-To: tim@binky.UUCP (Tim Wood)
Organization: Sybase, Inc.
Lines: 76

In article <637@daitc.daitc.mil> jkrueger@daitc.daitc.mil (Jon Krueger) writes:
>tim@binky.sybase.com (Tim Wood) writes:
>
>>Yes, but in order for the application to test against the system tables,
>>it has to send more query language text to the server! 
>
>Could be more, could be less.  It's the setup cost traded off against
>fewer transactions during the session.

Let's agree on the scenario.  For server checking, a batch of SQL
(procedure definition or ad-hoc) is sent straight to the server.  
Each batch must be validated on its own, independent of previously-run
batches.  

The server parses the batch and validates all name, datatype and
permissions usages (this is the bulk of the lookups to the system tables.)
That validation entails no communication to the client (unless there
are errors).  That validation need only be done once for as long as that
batch executes.  If the batch is a procedure, the validation need not
done again unless the database schema on which the procedure depends 
is changed.  

I'm not clear on what you mean by "setup cost".  The 
cost of the validations is amortized over the life of the procedure.
The more you use the procedure, the more insignificant the validation
cost becomes.  The only runtime validations are (optimized) schema 
and permission checks.  For ad-hoc (single-use) queries, client checking 
loses if it costs more than server checking, especially when the validation
cost is significant compared to execution cost. 

For client checking, the validations have to be done in SQL text.
Each "validation" query must still be validated in the server, so you've
added in the number of network messages needed to validate plus the number
of server validations of those messages to the batch validation cost.  
Those added costs don't exist for the server-checking case.  What's more, the
coupling between the validation and the compiled procedure here is much
looser, since a bundle of separate SQL queries must somehow be
associated with the procedure for the client case, whereas validation
is just an internal step in procedure processing for the server case.

>
>>...a lot more work will be done (compared to the same functions
>>performed within the server) to avoid the cost of sending the bad query
>>than just to send it and let the server signal any error!  
>
>Why not give an example?  I'll try to show how the cost could be
>higher either way, depending on workload.

The above explanation hopefully suffices (in lieu of designing a 
sample schema, giving a trace of network messages and 
estimated milliseconds per operation, which the question does
not justify.)   

>
>>Users expect friendly error handling from the server, regardless
>>of their applications; that's one of the inherent advantages and 
>>requirements of server designs.
>
>Users talk to a user agent, not a server.  Unless you're talking X
>Windows, of course :-)  Then again, Sybase glossies have been known to
>use the terms "user server" and "data server"; could that be the cause
>of confusion here?  Who's the client, anyway? :-)

True, I glossed over a level here.  Users expect friendly error handling
from (all) their applications.  Applications WRITERS expect complete,
descriptive and accurate error handling from the server, so they can
handle the errors properly in the application.  The "client"
is the process running the user application.  I haven't read the
"user/data server" lierature, so can't respond to that.
-TW


Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608	  415-596-3500
tim@sybase.com          {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim
Voluntary disclaimer: This message is solely my personal opinion.
		      It is not a representation of Sybase, Inc.  OK.