Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!caip!im4u!ut-sally!ark
From: ark@ut-sally.UUCP (Arthur M. Keller)
Newsgroups: net.unix-wizards,net.database
Subject: Re: A variant of the streams idea
Message-ID: <3886@ut-sally.UUCP>
Date: Sun, 29-Dec-85 00:21:37 EST
Article-I.D.: ut-sally.3886
Posted: Sun Dec 29 00:21:37 1985
Date-Received: Sun, 29-Dec-85 20:14:44 EST
References: <2416@ukma.UUCP> <372@ncr-sd.UUCP> <964@brl-tgr.ARPA> <376@ncr-sd.UUCP> <2afa6c05.3166@apollo.uucp>
Reply-To: ark@sally.UUCP (Arthur M. Keller)
Organization: U. Texas CS Dept., Austin, Texas
Lines: 47
Xref: linus net.unix-wizards:13433 net.database:151

In article <2afa6c05.3166@apollo.uucp> mishkin@apollo.UUCP (Nathaniel Mishkin) writes:
>At Apollo, we've developed a system for extending the concept of "stream".

I would argue that what you have really done is implemented the concept
of streams using the concept of objects.  Since the concept of objects
is at least as powerful as arbitrary procedure calls, this is not too
surprising.

>As you might guess, there are lots of uses for this facility.  For example,
>in the case of a DBMS, one simple facility you might want is to be able
>to read the DBMS like a sequential ASCII file, independent of what its
>real internal structure is.

This is the concept of information hiding.  You are using the features
common to streams and databases, so it is not surprising you can fit
a streams-like interface on top of a database.  It's also possible that
the streams-like interface was chosen to be a subset of the database-like
interface, but that's not necessary.

>If you were really ambitious, you might want to define a new trait --
>call it the "ISAM" trait -- that had operations like "seek_by_key" that
>took logical keys (i.e. NOT byte offsets) as arguments.

If you do decide to do that, I'd suggest supporting any number of keys,
not just one, and don't unnecessary bind the concept of a unique index
with the concept of a clustered index, but that's a whole 'nother
pet peeve of mine.

>Of course it's not clear that you could come up with a set of operations
>that made sense to enough different DBMS's to be worthwhile.  (Consider
>the question of what the term "key" means to different DBMS's.)  But
>it'd be interesting to investigate.

It should be possible to do it with any two databases designed using
the same model (relational, hierarchical, network, entity-relational,
functional, or what-have-you).  Furthermore, a sufficiently powerful
network-model database implementation could have a relational-model
interface on it, which to the user would be indistinguishable from a
relational-model database written using a traditional relational
implementation style.

Arthur M. Keller

-- 
------------------------------------------------------------------------------
Arpanet: ARK@SALLY.UTEXAS.EDU
UUCP:    {gatech,harvard,ihnp4,pyramid,siesmo}!ut-sally!ark