Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ginosko!brutus.cs.uiuc.edu!psuvax1!rutgers!att!cbnewsl!saify From: saify@cbnewsl.ATT.COM (saify.lanewala) Newsgroups: comp.databases Subject: Re: PC database Summary: Revelation (LONG RESPONSE) Message-ID: <2239@cbnewsl.ATT.COM> Date: 12 Oct 89 14:19:35 GMT References: <1205@orbit.UUCP> <12824@s.ms.uky.edu> <3848@deimos.cis.ksu.edu> Organization: AT&T Bell Laboratories Lines: 91 In article <3848@deimos.cis.ksu.edu>, connelly@deimos.cis.ksu.edu (Paul Connelly) writes: > How about "Revelations"? does anybody have any information on this? > It's supposed to be a DBMS for PC's. > > -- > W. Paul Connelly I have used Revelation since Revelation Version F was available circa 1983/1984. It's based on the Pick Operating System, and uses a similar dictionary- based approach to providing an integrated data definition, data manipulation and reporting environment. There are currently two major flavors available -- Revelation G (REVG) and Advanced Revelation (AREV). I don't know if REVG is still supported. Everything in Rev sits in logical files. Files contains records, records contains fields, which contains sub-fields etc. A record is a data dictionary item, or an R/BASIC program, or data for an employee etc. Major components of REVG are: 1. R/BUD -- dictionary builder 2. R/BASIC -- which is an enhanced BASIC producing compiled pseudocode 3. R/LIST -- which is an inquiry facility 4. TCL -- a terminal command language -- execute anything that's been cataloged 5. a report generator 6. a cataloging procedure -- catalog files, commands, new user-defined verbs plus some other assorted utilities. In particular, the dictionary is very powerful. Each item you define in this dictionary is essentially unlimited in length, and one describes a display length, which can be scrolled right/left so the entire field can be seen. You can assign simple or complex formulae to each field, and these can in turn be R/BASIC programs that are permitted to do file i/o. You can assign, again via the formaula field, an automatic table lookup, so you can assign a code to one field, and automatically have the corresponding description be available for the other field (for which you do the table lookup). The R/LIST processor allows SQL-like selects, sort-selects that you can use one-shot or catalog for future use. In my experience, this was the part about REVG that was quite clumsy for all its inherent power. It was also very slow as soon as the record size and the number of records grew beyond that needed for trivial applications. For example, a client of mine had a database with 5000 records, 1000 fields per record. A typical R/LIST command to retrieve records from that database sorted by a non-key field could easily take upto 40 or 50 seconds. Typical response for a similar database using a C database library took about 9 seconds. The other annoying thing about REVG is the file layout (which the user never sees). REVG stores files in 64K chunks. This means that a large database gets broken up into N 64K chunk DOS files. A hashing algorithm determines which of these 64K chunks is needed. The entire 64K chunk is read in. The other implication of this has to do with certain R/BASIC language features. You are allowed to CALL 'external' subroutines (external to the R/BASIC program); these external subroutines have to be cataloged in a REVG file. The first time you use one of these subroutines, there is a noticeable delay while REVG searches for this subroutine, then loads it, and executes it. Subsequent calls to this subroutine naturally are fast. Unfortunately, if you have enough of these externals, eventually one of the loaded subroutines is swapped out... Finally, there is a cross-reference facility, but no indexing, so ... ADVANCED REVELATION: In an attempt to fix some of these problems, plus add a lot more new features, Advanced Revelation was created. For one thing, b-tree indexing was added; the Revelation filing mechanism was changed; a bunch of windowing stuff was added. I haven't really had much of a chance to dig deep into AREV, but will have an opportunity to do so in the near future. I'll be able to provide a better summary then. Sorry about the long article again. Saify Lanewala .... attunix!stl