Thread View: net.database
2 messages
2 total messages
Started by Eric Bergan
Thu, 29 Aug 1985 19:44
Re: UNIX dbms
Author: Eric Bergan
Date: Thu, 29 Aug 1985 19:44
Date: Thu, 29 Aug 1985 19:44
48 lines
3335 bytes
3335 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). > 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
Re: UNIX dbms
Author: Jerry Lieberthal
Date: Sat, 31 Aug 1985 01:29
Date: Sat, 31 Aug 1985 01:29
48 lines
3128 bytes
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 ***
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads