RE: scsh in PLT Scheme?

["Alex Peake" <apeake@comac.com>]

> -----Original Message-----
> From: Bruce Butterfield [mailto:bab@entricom.com]
> Sent: Tuesday, April 02, 2002 8:46 PM
> To: Alex Peake
> Cc: Anton van Straaten; MJ Ray; plt-scheme@fast.cs.utah.edu
> Subject: Re: scsh in PLT Scheme?
>
>
> 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.

The issue I was getting at is the resources consumed in the database engine
holding a connection.

You are quite correct about using pooling to relieve (time) overhead of
creating connections.


>
> >
> >
> >>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!
>

Again, why did you select that particular (sub) set of data? Do you want it
or do you not?

> >
> >
> >>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
>
>