🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.database
Article #142

Re: UNIX dbms

#142
From: Jerry Lieberthal
Date: Sat, 31 Aug 1985 01:29
48 lines
3128 bytes
> >     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).
> 
	Has Unify changed significantly in the last two years? Last I knew,
> still completely copies the data out of the storage and then back in. If your
> >     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)
> 	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

We have been playing with version 3.1 (I understand version 3.2 is in testing, 
and should be out soon).  My opinion is that for 90% of simple things Unify
comes up with applications very quickly.  For our production center people
(i.e. non-programmers) it will work out nicely, as long as they don't try
too complicated a query.  Joins and aggregates are extremely SLOW.  I
wonder what version 3.2 will fix and/or extend?  Anyway, for the price
(in a university setting) it was attractive for what we initially needed it
for.  I am going to try to evaluate RTI INGRES for the complicated things
we will want to do in the near future...

	- jerry      ihnp4!uwmcsd1!jerry
	  University of Wisconsin-Milwaukee

"insert into net.database:
	<'nasty comments'> /
FATAL ERROR ...

*** REPLACE THIS LINE WITH YOUR MESSAGE ***
Technical Details
Message-ID: <407@uwmcsd1.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!ihnp1!ihnp4!uwmcsd1!jerry
References: <494@osiris.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site uwmcsd1.UUCP
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!ihnp1!ihnp4!uwmcsd1!jerry
From: jerry@uwmcsd1.UUCP (Jerry Lieberthal)
Newsgroups: net.database
Subject: Re: UNIX dbms
Message-ID: <407@uwmcsd1.UUCP>
Date: Fri, 30-Aug-85 21:29:15 EDT
Article-I.D.: uwmcsd1.407
Posted: Fri Aug 30 21:29:15 1985
Date-Received: Sat, 31-Aug-85 21:27:34 EDT
References: <494@osiris.UUCP>
Distribution: net
Organization: U of Wi-Milwaukee, Computing Services Div
Lines: 48