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