Path: utzoo!attcan!utgpu!watmath!att!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!gem.mps.ohio-state.edu!apple!sun-barr!cs.utexas.edu!uunet!ncrlnk!usdtsg!klint From: klint@usdtsg.Dayton.NCR.COM (W. E. Klint) Newsgroups: comp.databases Subject: Re: Parsing Query Languages in the Client or Server (long) Keywords: SQL, query, client, server, database Message-ID: <346@usdtsg.Dayton.NCR.COM> Date: 21 Sep 89 14:54:48 GMT References: <6155@sybase.sybase.com> Reply-To: klint@usdtsg.Dayton.NCR.COM (Bill Klint) Followup-To: comp.databases Organization: NCR Corporation USDPG/ISS Systems Support, Dayton Lines: 65 Summary: Expires: In article <6155@sybase.sybase.com> forrest@sybase.com writes: >...At Britton Lee query languages were parsed in the clients and parse >trees were sent to the server. Here at Sybase we send the query >language to the server to be parsed. > >I'd like to hear peoples comments about the strengths and weaknesses >of both approaches. > The following is an article I posted for NCR distribution. I post it here in reply to your request, and in hope that it contributes to what I consider an essential question of future database/query architecture. ****************************************************************************** The following is ...[text deleted}...intended to generate discussion on client/server database architectures. Perhaps this discussion can precipitate, at the very least, clarification of a perceived problem, perhaps acknowledgement of a problem, and, at best, architectural changes. SQL has become, or is becomming, the de-facto standard relational database query language. The pure implementation of SQL in a client/server architecture seems rediculously simple; the client passes an SQL command to the server where it is parsed and executed and the solution set then is returned to the client. In actuality, it appears that almost all proprietary database vendors have seen fit to address the most economically expedient short term solution; convert SQL commands to their native database language commands, at the client, send them to the server, where, if the server runs their proprietary DBMS, everything is copacetic. However, if the server happens to run another proprietary DBMS, an interface must be built to convert vendor A's proprietary calls to vendor B's proprietary calls, or, since all vendors support SQL, convert the proprietary calls back into SQL where they can easily be converted to vendor B's proprietary DBMS calls. I know that off-loading processing to the client is one of the benefits of the client/server architecture. But the above described implementations seem to double the amount of processing required for data retrieval at *both* the client and the server! If ...[text deleted]... vendors were to incorporate a "pass-through" facility where, if selected, one could choose not to utilize that particular vendor's call library, but merely pass the ASCII SQL text through to the communications interface for transmittal to the server, things would be greatly simplified. At the server (whatever the DBMS), that SQL could be converted to database calls and a solution set derived and passed back to the client. This would provide for truly *open* systems. An ASCII SQL command could come from a batch program, an interactive terminal or a client application from any "foreign" client. Any server that recognizes ASCII SQL could then use whatever means necessary to satisfy that particular request. This would allow vendors to implement "back-end" strategies to best satisfy customer (client) demands.... ****************************************************************************** The checking of SYNTAX at the client should be considered a MUST. Its not worth network overhead if the query is syntactically incorrect. However, if we are to achieve truly OPEN DISTRIBUTED database systems, I feel we must let the servers interpret the query, generate the appropriate library calls (for their specific DBMS), compile a solution set, and return this solution set to the client. Please note that these are personal opinions and do not necessarily reflect those of NCR. -- William E. Klint USDPG, Information Systems & Services, Systems Support NCR Corporation, SDC-5 | Bill.Klint@Dayton.NCR.COM 1700 S. Patterson | klint%usdtsg.Dayton.NCR.COM@RELAY.CS.NET Dayton, OH 45373 (513) 445-3483 | klint%usdtsg.Dayton.NCR.COM@uunet.uu.net