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.