Re: scsh in PLT Scheme?

[Anton van Straaten <anton@appsolutions.com>]

I agree that it's OK for the *default* behavior to deliver the entire 
requested set.  There is a case, though, for supporting alternatives. 
 It can depend on the nature of the client software.  For example, a 
user may request a relatively large dataset and then browse through it 
looking for something, e.g. by using a Page Down key.  Preloading the 
entire set in a case like this may be prohibitive (not to mention 
wasteful).  It can be important for the database interface to provide 
control over when and how much data is fetched.

Even if you argue, as some do, that query interfaces that return large 
recordsets "shouldn't be allowed", that still doesn't handle the case 
where you have a set that's longer than fits on one page or screen, and 
you want to begin displaying the data before all the data is retrieved. 
 This can also be addressed by having data retrieval support an 
asynchronous mode (which is a nice feature anyway).

With web-based clients, the preloading issue is less likely to arise 
(although it still can), because an individual web page usually displays 
a relatively small amount of data.

I don't think it's unacceptable to have a database interface that 
preloads its data (although an asynchronous loading option would be 
useful in that case), but I think it's kidding oneself to believe that 
nothing is lost by this kind of restriction.  Databases are used in many 
different ways, with different usage patterns.  Two-tier client/server 
applications with logic in stored procedures and/or in the front end 
have very different database access patterns than multi-tier systems 
which have application logic layers outside the database, for example. 
 I've yet to see a one-size-fits-all approach that's viable across these 
different situations.

Anton

>Databases are about set operations. If you want data you ask for it. If you
>only want a subset you only ask for a subset. If you want to do updates use
>set operations to update on the server.
>
>Default behavior should be to deliver the set requested.
>
>Alex
>
>>-----Original Message-----
>>From: owner-plt-scheme@fast.cs.utah.edu
>>[mailto:owner-plt-scheme@fast.cs.utah.edu]On Behalf Of MJ Ray
>>Sent: Tuesday, April 02, 2002 4:32 PM
>>To: Bruce Butterfield
>>Cc: plt-scheme@fast.cs.utah.edu
>>Subject: Re: scsh in PLT Scheme?
>>
>>
>>Bruce Butterfield:
>>
>>>I would argue that often it is necessary to walk through large sets of
>>>query data on a row-by-row basis to do some external processing
>>>
>>I can see two options, really: use cursors as you say to batch
>>the transfer
>>to scheme for processing, which could probably be implemented inside the
>>DB:for-each interface (although I wouldn't want to be the person to try to
>>do that); embed scheme into your database and pass it a function to use.
>>
>>Is there another good solution which offers something the above doesn't?
>>--
>>MJR
>>
>