Re: scsh in PLT Scheme?

[Bruce Butterfield <bab@entricom.com>]

Alex Peake wrote:
> You are right in that this *default* behavior should not be the *only*
> behavior, but... (see below)
> 
> 
>>-----Original Message-----
>>From: Anton van Straaten [mailto:anton@appsolutions.com]
>>Sent: Tuesday, April 02, 2002 6:51 PM
>>To: Alex Peake
>>Cc: MJ Ray; Bruce Butterfield; plt-scheme@fast.cs.utah.edu
>>Subject: Re: scsh in PLT Scheme?
>>
>>
>>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.
>>
> 
> 
> What is mostly wasteful in databases is the overhead (in the database) of
> connections. Hence the strategy of connecting, requesting some data,
> downloading it all and then disconnecting. It usually costs less to request
> all the data (that you think you will need) and display page at a time from
> the downloaded data, than to keep a connection open to the database. As an
> alternate, you can always request subsets. The cost (on the database engine)
> is always less.
>

Connection pools. Work great, less filling.

> 
> 
>>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).
>>
> 
> 
> What fits on the page is not necessarily correlated with what is downloaded.
> You can easily display subsets of what you have doanloaded. Also, you should
> ask yourself "what data do I need and why"? Think about why your query asked
> for a large recordset.
> 
In an ideal world I could do a zero-cost prequery to find out if it's 
gonna be too expensive. Whoops, I just found out it was!

> 
> 
>>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.
>>
> 
> 
> See the previous statement.
> 
> 
>>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.
>>
> 
> 
> I would not advocate a single pattern of access. Just remember that the
> costs are mostly associated with keeping connections open, not with
> dowloading data. If you think about what data you need, then most of the
> time, all of what you requested (and you have very fine control over that)
> is exactly what you need.
> 
> 
> Alex