RE: scsh in PLT Scheme?

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

Some "truisms" (straight from the manual)

It is always more efficient to filter data at the server than to send it to
the client and filter it in the application.

It may seem economical to request a default result set and fetch rows only
as your application logic or your application user needs them, but this is
false economy. Unfetched rows from a default result set can tie up your
connection to the server, blocking other work in the same transaction.

Some applications cannot buffer all the data they request from the server.
For example, an application that queries a large table and allows the user
to specify the selection criteria may return no rows or millions of rows.
The user is unlikely to want to see millions of rows....
..server cursors that allow an application to fetch a small subset or block
of rows from an arbitrarily large result set....
..However, the features of server cursors come at a cost. If all the
results from a given query are going to be used in your application, a
server cursor is always going to be more expensive than a default result
set...


I am not trying to say that the only way to fetch data is a careful query
followed by downloading all results. Only that this is the default (or
primary) method and should be so addresses in a scheme to access databases
from Scheme.

Alex


> -----Original Message-----
> From: Anton van Straaten [mailto:anton@appsolutions.com]
> Sent: Tuesday, April 02, 2002 9:19 PM
> To: Alex Peake
> Cc: plt-scheme@fast.cs.utah.edu
> Subject: Re: scsh in PLT Scheme?
>
>
> > Also, you should ask yourself "what data
> > do I need and why"? Think about why your
> > query asked for a large recordset.
>
> One of the points I was making is that sometimes, you'd have to
> extend this logic to the end user to make it work.  And that's
> not always valid - you're basically telling them "no, you can't
> use the system the way you'd like to".  In heavily loaded
> environments, you might be forced to say this because of load and
> performance considerations, but in many other cases, it's
> perfectly doable, and the only thing standing in the way of such
> capabilities are developer sensibilities, which may often be
> misapplied.  Developers often want to micromanage how end users
> use a system, which can get in the way of usability.
>
> For example, database connections aren't noticeably wasteful in
> an environment where the database isn't overstressed.  Gearing
> APIs and architectures for the most large-scale environments can
> be actively hostile to smaller-scale development.
>
> > What fits on the page is not necessarily correlated with what
> is downloaded.
> > You can easily display subsets of what you have doanloaded.
>
> See my comment about the need for asynchronous download.  If you
> don't have that, then you have to wait for the entire set to
> download before display can begin.  This can be a problem at
> multiple levels.
>
> > 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.
>
> That's a bit contradictory: costs aren't all absolute, they can
> depend on access patterns and be relative to system resources.
> Downloading data can be a major concern over a slow link, but
> open connections aren't necessarily a concern for a departmental
> application as opposed to e.g. a public web site.
>
> In fact, with multi-CPU, multi-gigahertz servers with gigabytes
> of RAM being available for a few $1000, database performance is
> often much less of an issue than it once was, for many
> applications.  Big public web sites or large organizations are a
> highly visible exception to this, and to a large extent they're
> driving the conventional wisdom on these issues.  That "wisdom"
> may not be universally applicable, though.
>
> Anton
>
>
>
>