RE: scsh in PLT Scheme?

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

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.


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


> 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

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