Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!voder!nsc!amdahl!rtech!squid!robf From: robf@squid.rtech.com (Robert Fair) Newsgroups: comp.databases Subject: Re: Do you like your UNIX RDBMS? Message-ID: <2948@rtech.rtech.com> Date: 1 Jun 89 14:50:22 GMT References: <9703@dasys1.UUCP> <3378@fp.sei.cmu.edu> <2907@osiris.UUCP> <427@fdmetd.uucp> Sender: news@rtech.rtech.com Reply-To: robf@squid.UUCP (Robert Fair) Organization: Relational Technology, Inc. Lines: 62 > >In article Steinar Overbeck Cook, writes: >> What is wrong with the use of embedded SQL ?. With the use of embedded >> SQL your 'C' programs are much more portable than with the use of some >> proprietary C-interface. Personally I use Pro*C with our Oracle >> database. The precompiler from Oracle is lousy, but I like embedding >> SQL in my C-programs. >> > >The problem with Embedded SQL is that is super lousy for browsing thru' a >database. Suppose you issue a query and there are 1000 matching records. >Are you aware that ALL the current ESQL implementations require that you >WAIT FOR THE 1000 RECORDS TO BE FOUND EVEN BEFORE YOU CAN VIEW THE 1ST ONE? >Thus your client will be FORCED to wait for up to 5 minutes before he/she >gets a response from a simple query! This is completely untrue ! There is no constraint in SQL systems which says that you have to wait for all the data before you get the first row. Certainly INGRES normally allows you to start looking at data as soon as the first row in the resultant dataset has been found - in R6 both cursors and the SELECT-loop do this. [In R5 things were more complex with multiple cursors] >This certainly is NOT PROGRESS. Remember that in _LOWLY_, pseudo-relational >Dbase III you can access the 1st record of a matching set super-quickly by >using filters and the other records by doing a SKIP. >Also this can be done similarly in Informix 3.3. (I think this goes to show >that we need 2 simultaneous database models. Relational and Network!) >Also, another sore point with a DBMS like ORACLE is that you can't access >a PREVIOUS record. ie. you can't browse backwards. THIS SUCKS!! >Again, in lowly Dbase, all you have to do is SKIP -1. In the latest ANSI SQL standard there is a proposal to add FETCH PREVIOUS to cursors to do exactly what you want. > >*** DO YOU NOW SEE WHAT IS WRONG WITH EMBEDDED SQL!!! *** > >--- Emuleomo O.O. (Disgusted with Embedded SQL!!) The problem with programs like DBASE is that they limit you to a specific implementation. By using SQL/ESQL your programs are portable across multiple machines and vendors - by using COMMON-SQL* my applications should run on INGRES, RDB, DB2, etc without any change! There are many other benefits to using ESQL (or a call-interface that takes SQL, like SYBASE), over a low-level record interface, including: - The SQL query is at a higher level of abstraction, so it should be more compact, maintainable & easy to read. This is especially important for complex multi-table queries. - It allows the DBMS to have a decent query optimizer, instead of having to hard-code access paths. This makes schema changes easier and the code more maintainable & easier to read. - Since the SQL & ESQL syntax is so similar, ESQL queries can usually be bench-tested in interactive-SQL before being implemented, saving lots of debugging time later. Robert L. Fair RTI Tech Support