Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!mit-eddie!cybvax0!vcvax1!paul
From: paul@vcvax1.UUCP (paul)
Newsgroups: comp.databases
Subject: Re: Optimization algorithms
Message-ID: <204@vcvax1.UUCP>
Date: Sun, 14-Dec-86 15:59:49 EST
Article-I.D.: vcvax1.204
Posted: Sun Dec 14 15:59:49 1986
Date-Received: Tue, 16-Dec-86 18:51:59 EST
References: <8612010047.AA14252@BORAX.LCS.MIT.EDU> 9768@sri-spam.istc.sri.com <8988UH2@PSUVM>
Distribution: world
Organization: VenturCom Inc., Cambridge, MA
Lines: 27

> 2.  By adding structure to your phone book, you are gonna lose the
> transparent interface to other tools provided by the shell.

Not necessarily.  The database in our (VenturCom's) Prelude
Information Management System product has a similar challenge: to use an
ASCII database format, compatible with existing UNIX tools, and
yet provide a fast look-up mechanism.

Our solution is to use a daemon, called the Record Management
System (RMS), which maintains a btree index (in a separate file)
to the database.  Programs which wish to locate a record quickly
communicate with the RMS to find records.  The RMS is also used
to update records in the table, as well as maintain locks.
However, since the actual table is always kept in ASCII format,
other UNIX programs are free to read it directly.  (The one
constraint is that they are not permitted to write to it
directly, since that would cause inconsistencies between the
file's contents and the RMS btree.)

The result is that we can maintain an ASCII, "open-architecture"
data format, and still provide fast record access when desired.

------------
Paul Kleppner
VenturCom, Inc.
617/661-1230
{seismo!harvard,genrad!mit-eddie}!cybvax0!vcvax1!paul