Re: Model question

>
>> Date: Sat, 26 Jul 2003 16:29:57 -0400
>> From: "LeVan,Ralph" <levan@oclc.org>
>> 
>> Result sets are NOT databases.  The model claims that they are
>> reasonably static.  Databases are not static.
>
Reasonbly stabile in the sense that the set definition is stabile---
the query against a target at a given moment in time with some specific
lifespan--- yet the presents of its elements can be volatile--- where,
for example, the present (as we do in some projects) is via an SQL
statement to an RDBMS while the search (DB) that creates the result set
is via a snapshot/view of that RDBMS at some specific point in time (which
this approach we have been able to handle e-commerce databases with
many millions of items)... The set then of a result is something quite
different from the set of the instantiations of its elements!


>I'm not in a position to comment on history.  However, I can't let
>this discussion go past without observing that, in this day and age,
>there's no reason to perpetuate this historical distinction between
>databases and result sets -- or, for that matter, between
>databases/result sets and records.  They're all just lumps of data,
>structured together in various ways.

I disagree.. While at the "atomic" level they are just streams of octets..
which get lumped and clustered in some way to define concepts of "information
chunk" to object to record/document to database to result or whatever.. The
concepts of database, record, result set etc. have their own kinds of
methods that can be applied. 

Can or should we start to try to apply all the methods in a consistent
manner across target, result set and presents?

While many things can be "theoretically" done some would entail very high
costs for minimal utility.

Scan services come to mind. Scan of an arbitrary result of a query would,
I argue, have for most systems very high costs. I like to also scan elements
so how would an implementation of a scan for some children in a tree of all
these trees in some arbitrary forrest?

I have customers with many GBs in many millions of records..  I don't think such
a feature would be reasonable at this time..  Sure hardware and my algorithms
are getting faster but so are the amounts of data.  A scan of such would
typically be slow.  Very slow and demand significant system resources but
provide little utility.  We don't have "excess" resources...  Many, if not most
of us, have been in "this game" for over a decade and looking back we used to
think "Wow 100 MB" that's massive..  and today?  I have users indexing genetic
sequence databases!  That magic number for "wow" is no longer 100 MB but maybe
100 TB!  And we have often more users..  so the "improvements" are being chased
by increases in demands upon it..

Scanning methods, like some others we have defined for databases, I'll argue
are fine for "objects" that last long enough to be worth preperation (or even
can be prepared for) or those that come with little costs (a very implementation
specific thing whence outside the domain of what I'd call an acceptable feature
for a standard) but not for "anything".

We also have set operations (or query operations) that define word
metrics, handle the heirarchical structure of data (e.g. XML queries) etc.
and to apply these to "present" would, of course, be silly.. A universe
with a single record is just not very interesting for these kinds of methods
is it not? 

And Present methods.. do we really want to start to define these to 
arbitary sets (not just singlets or sets of singlets)? 

The distinction, in this vein, between object instantiation (Present), 
collection (result set) and domain (target/database) I think makes sense.
Each can get its own set of methods. Tossing this distincition would, I continue
to allege, would weaken things to create a most minimal subset of methods..
or demand implemenations that only exist on paper..

______________________
Edward C. Zimmermann, Basis Systeme netzwerk, Munich
<A 
HREF="http://www.stadtplandienst.de/query;ORT=m;PLZ=80802;STR=Leopoldstr%2E;HNR=
53;GR=2;PRINTER_FRIENDLY=TRUE">Leopoldstrasse 53-55, D-80802 Munich, Federal 
Republic of Germany</A>
Telephone:   Voice:= +49 (89) 385-47074  Fax:= +49 (89)  692-8150
          Cellular:= +49 (179) 205-0539

Received on Sunday, 27 July 2003 06:36:46 UTC