Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site osiris.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!genrad!panda!talcott!harvard!seismo!umcp-cs!aplvax!osiris!eric
From: eric@osiris.UUCP (Eric Bergan)
Newsgroups: net.database
Subject: Re: UNIX dbms
Message-ID: <494@osiris.UUCP>
Date: Thu, 29-Aug-85 15:44:27 EDT
Article-I.D.: osiris.494
Posted: Thu Aug 29 15:44:27 1985
Date-Received: Sun, 1-Sep-85 12:14:41 EDT
Distribution: net
Organization: Johns Hopkins Hospital
Lines: 48

>     It may be good for users, but have you seen all of the low level toys ?
> They include just about all of the basic hooks into the system you could
> want.  That is a lot more than be said of most systems (that I have seen).
> They also offer a wide variety of tools and access methods to the data. 
> For a manager (of the system) there are several ways to maintain basic data
> format and it's easy to reconfigure and optimise after installation.  And
> the end user gets all of the generic access stuff plus whatever the
> software people customise from the tools.  Even operations people make
> batch updates and gobs of reports.

	Has Unify changed significantly in the last two years? Last I knew,
there was no embedded non-procedural languages - the programs had to explicitly
know all about the data structure. In relational databases, this is a no-no - 
you are supposed to have independence from the physical partitioning of tables.
Also, last I looked, Unify only supported a hash as the primary index, and only
B-tree on secondary indices - has this changed? As for reconfiguration, it
still completely copies the data out of the storage and then back in. If your
database is a full Eagle's worth of data, you need an extra Eagle or a lot
of time with tape to reconfigure. 

>     The scale is of the task is of little significants as you can whip up a
> flat system with input screens in a few minutes and let it grow in to a
> major integrated system as time goes on.  Since it was written with the 
> smaller systems in mind it fits into a lot of smaller environments. However,
> that does not restrice it's upward abilities.  UNIFY is ideal (in my opinion)
> for most fixed record tasks.  It's overall performance is it's strongest
> point.  Of course it is a little difficult having so many ways to perform
> tasks.

	Its lack of good locking, journalling, and multi-statement transactions
makes it a little suspect for a large production application.

	In benchmark's I performed between Unify and Ingres, Unify was
definitely faster than Ingres on the simple single table lookup, append, or
replace. But it was significantly slower in doing joins, aggregates, or
projects. If memory serves, there was one three table join that took Ingres
3 minutes, and Unify over 300 minutes. While it does support pre-joins, these
have to be compiled ahead of time, and may be useless in an ad hoc query
environment.

	I do want to stress that it has been two years since I did this
comparison, and Unify certainly has changed at least some in that time. Can
anyone tell me if these particular failings have been corrected?

-- 

					eric
					...!seismo!umcp-cs!aplvax!osiris!eric