Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!brunix!iris.brown.edu!jhc
From: jhc@iris.brown.edu (James H. Coombs)
Newsgroups: comp.databases
Subject: Re: Information wanted on Db Vista
Message-ID: <17731@brunix.UUCP>
Date: 12 Oct 89 18:46:04 GMT
References: <1989Oct11.141207.18348@kadsma.uucp>
Sender: news@brunix.UUCP
Distribution: usa
Organization: IRIS
Lines: 59

In article <1989Oct11.141207.18348@kadsma.uucp> fuller@kadsma.uucp (Bill 
Fuller) writes:
>     I am about to embark on project where the client will be asking me
>to develop a system using the dbVista package.  I know very little about it
>other than it is a network database that you can get the source for.  I would
>reaaly appreciate any comments on it from people who have used it, and any
>comparisons that could be made to better know products.  One other note; I
>will be using a SUN under SunOS 4 for the project.

We have used Faircom's c-tree for a year now, with very good results.  (We
used Ingres before, but we had a lot of problems with database 
administration, and few wanted to purchase and install Ingres so that they could run Intermedia.)  c-tree does not have a good ad hoc query capability, 
so I ordered the recent special: db_Files and db_Retrieve.  (The names may 
be slightly off.)  I sent it back.  Why?

1. No varying length records.  c-tree supports not only varying length 
records but also compression of keys in indexes.  I have databases of 25 
Mb and  up, so compression (of English words, file pathnames, etc.) can 
save a lot of space.

2. The network model sounds good at first, but the overhead for the 
pointers to the next and previous records in the set adds up quickly.  I 
have forgotten the details of the data structures, but my judgment was that I 
would not save significant space.

3. Retrieval of a set from the network model should be faster than 
traversing an index---but how much faster?  I don't have performance 
problems with c-tree, so there is not much motivation to do the work 
required to make
a full comparison.

4. c-tree uses Unix record locking.  db_Files locks entire files or leaves 
it to the application developer to implement their (simple) record-locking
scheme.

5. I was after the SQL.  The documentation for db_Files was very 
impressive; the documentation for db_Retrieve was not.  db_Retrieve 
included an ad hoc apparatus for marrying SQL to the network database.  I 
never worked through the details.  db_Retrieve does not optimize queries.  
My judgment was that I would be inviting trouble and would have to 
implement my own query engine in the end anyway.

db_Vista and db_Query may be a lot better.  My impression is that they are
not enough better to justify the cost.  In any case, my experience with 
c-tree is very positive, and db_Files/db_Retrieve did not look good enough 
to inspire further investigation at this time.

I heartily recommend c-tree, and I'm in very good company on this
recommendation.  (I found that people on bix recommend c-tree and
rarely mention db_...)  r-tree is ok; I use it once in a while.  I sent 
d-tree back; although it may be better now, it doesn't address our needs 
anyway.

--Jim

Dr. James H. Coombs
Senior Software Engineer, Research
Institute for Research in Information and Scholarship
Box 1952, Brown University, Providence, RI 02912