Path: utzoo!mnetor!uunet!husc6!bbn!gatech!ukma!psuvm.bitnet!uh2
From: UH2@PSUVM.BITNET (Lee Sailer)
Newsgroups: comp.databases
Subject: Re: Informix query
Message-ID: <29617UH2@PSUVM>
Date: 12 Jan 88 19:01:09 GMT
References: <3072@ihlpf.ATT.COM> <3890001@hpcmmb.HP.COM> <3216@ihlpf.ATT.COM> <29265UH2@PSUVM> <71@coot.AUSTIN.LOCKHEED.COM>
Organization: Penn Sate Erie--School of Business
Lines: 34

In article <71@coot.AUSTIN.LOCKHEED.COM>, chris@AUSTIN.LOCKHEED.COM (Chris Wood) says:
>
>In article <29265UH2@PSUVM>, UH2@PSUVM.BITNET (Lee Sailer) writes:
>> I've never used any SQL product, but supposedly know some of the underlying
>> ideas.  How about something like
>>
>> good customers = Select count(id#)
>>               <code deleted>
>
>All of this is fairly close, but the point is that I could do it in
>1 query with M204, but a single query in SQL can only do a single thing.
>This means that if I want to do several things to the same set of
>records, I must re-retrieve those records for each function.  I guess this
     
As the technology improves, you will see optimizers that recognize
when two queries could be more efficiently executed in parallel, and
will automagically arrange this for the user.  Currently, disk cacheing
schemes can do nearly the same thing.  The only hope for optimizers in the
future is to limt the set of allowable constructs today.
     
     
     
>Question: I am (embarassingly) unfamiliar with CURSORS.  Will they
>solve some of this problem?
>
     
As others have described, cursors are the mechanism that lets SQL be
embedded in languages such as C, PL/1, and  COBOL.  Indeed, they solve
many problems.
     
However, they also allow the data base security and integrity schemes
to be subverted, and so must be used by knowledgable programmers, and
not by the average end-user.