kmk@hlwpc.UUCP (Ken Keyzer) (08/15/85)
Let's start with something simple :-) What is the best UNIX database management system? Why? -- Ken Keyzer AT&T Bell Laboratories ihnp4!hlwpc!kmk
olson@dataio.UUCP (Darryl Olson) (08/16/85)
In article <589@hlwpc.UUCP> kmk@hlwpc.UUCP (Ken Keyzer) writes: >>Let's start with something simple :-) >> What is the best UNIX database management system? Why? >> Best relative to what criteria? I prefer that we start by defining a set of criteria to evaluate dbms before we start publishing the results of our evaluations. Darryl Olson ... uw-beaver!teltone!dataio!olson
jerry@uwmcsd1.UUCP (Jerry Lieberthal) (08/18/85)
> Let's start with something simple :-) > What is the best UNIX database management system? Why? > So far I have seen only UNIFY and ORACLE. I don'T count INGRES because the University here only gets the "toy" version. At any rate, for ease of use and non-programmability (for non-programmers) I vote for UNIFY at the present time. Also, the SQL language is fairly simple. What I liked best was being able to substanstially change the scheme and reconfigure the database with one command and not lose any data or have to reload the database.. - jerry ihnp4!uwmcsd1!jerry Computing Services Division - Univ. Of Wisconsin-Milwaukee
jmc@ptsfa.UUCP (Jerry Carlin) (08/19/85)
In article <589@hlwpc.UUCP> kmk@hlwpc.UUCP (Ken Keyzer) writes: >Let's start with something simple :-) > What is the best UNIX database management system? Why? > There is no one 'best'. I would choose Unify if I needed a large (say 10-250 megabyte) database, Ingres if I wanted a dbms with all the bells and whistles and Informix if I wanted something that also ran on pc's. -- voice= 415 823-2441 uucp={ihnp4,dual}!ptsfa!jmc
throopw@rtp47.UUCP (Wayne Throop) (08/19/85)
In article <776@dataio.UUCP> olson@dataio.UUCP (Darryl Olson) writes: >In article <589@hlwpc.UUCP> kmk@hlwpc.UUCP (Ken Keyzer) writes: >>>Let's start with something simple :-) >>> What is the best UNIX database management system? Why? >>> > >Best relative to what criteria? I prefer that we start by defining a set >of criteria to evaluate dbms before we start publishing the results of our >evaluations. > >Darryl Olson >... uw-beaver!teltone!dataio!olson > I expect that the criteria for the evaluation were the "Why?" part of the question. Thus, this survey can kill several birds with one posting (or, as it turned out, three postings), by getting evaluations along with evaluation strategies. -- Wayne Throop at Data General, RTP, NC <the-known-world>!mcnc!rti-sel!rtp47!throopw
horton@fortune.UUCP (Randy Horton) (08/20/85)
In article <589@hlwpc.UUCP> kmk@hlwpc.UUCP (Ken Keyzer) writes: >Let's start with something simple :-) > What is the best UNIX database management system? Why? > The question of "what database software is best" is dependent upon the intended users of the database(s), and the specifics of an application. There are tradeoffs of power, flexibility, and ease of use (both by the programmer and the users). In my situation, I develop databases for use by non-programmers. Many of the users of my databases not only do not know much about computers, they are not particularly interested in learning about them. They just want to get their work done. This has a great influence on my choice of "the best database software". For my needs, I have found INFORMIX (tm of Relational Database Systems) the best all around package. Most database packages offer similar capabilities for defining database structure, so I will address what I feel are the two especially strong points of Informix: the data entry screen generator and the report generator. PERFORM (tm)is the data entry screen generator of Informix. It allows the programmer to create sophisticated data entry screens faily easily. Naturally the programmer has total control over the appearance of the screens. You can validate data by range checks, accepting only a certain format of data, and lookups from other files. Newly added to Perform is a feature called instruction blocks. These instruction blocks give the programmer the capabilities to create truly sophistcated screens. You can control cursor movement depending on what type of function (add or update) is being performed, as well as depending on what value or range of values was entered into a specific field or fields. You can creadte display fields that are not part of any file, which can take on values based on calculations based on other fields. You can perform calculations and lookups on entered field values and take actions based on the entered values or on the results of the calculations. For example, you could take the values entered into several fields, perform a calculation using those values, use the result of the calculation to perform a lookup from another file, enter the value returned from the lookup into another field, and then move the cursor to any other field based on the results of any of the previous steps. You can also call your own C language functions which could themselves perform extensive manipulations of the database. The report writer, ACE (tm) also provides extensive capabilities. Ace is actually a programming language, sort of a fourth generation language. You write a report program and compile it. The compiled file is then used to actually generate the final report. The report program can be passed paramaters, or it can prompt the operator for input. Of course in a case where the program prompts the operator for input, input could be redirected from a file containing the values to be input. I combine this capability with other programs which update the input files to run various reports at various times automatically in conjunction with cron. You can define variables and perform extensive calculations using the variables and database fields. You can also call C language subroutines. As long as this posting is, I have barely scratched the surface of the capabilities of Informix. The query language is equal to any I have seen, but it is similar to most. I would be happy to answer specific questions about Informix. I am not an employee of, or have any connection to Relational Database Systems. I am just a very satisfied customer. -- +---------------------------------------------+ | allegra\ Randy Horton @ Fortune Systems | | cbosgd \ | | dual >!fortune!ranhome!randy | | ihnp4 / | | nsc / Clever disclaimer goes here | +---------------------------------------------+
fbp@cybvax0.UUCP (Rick Peralta) (08/21/85)
In article <393@uwmcsd1.UUCP> jerry@uwmcsd1.UUCP (Jerry Lieberthal) writes: > ... At any rate, for ease >of use and non-programmability (for non-programmers) I vote for UNIFY at >the present time. > >Also ... 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. 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. Any counterpoint comments or opinions, public or private, welcome. Rick ...!cybvax0[!dmc0]!fbp "Long live Darwinism ... 'till something better comes along"
saltiel@cdstar.UUCP (Jack Saltiel) (08/22/85)
In article <818@ptsfa.UUCP>, jmc@ptsfa.UUCP (Jerry Carlin) writes: > In article <589@hlwpc.UUCP> kmk@hlwpc.UUCP (Ken Keyzer) writes: > >Let's start with something simple :-) > > What is the best UNIX database management system? Why? > > > There is no one 'best'. I would choose Unify if I needed a large > (say 10-250 megabyte) database, Ingres if I wanted a dbms with > all the bells and whistles and Informix if I wanted something that > also ran on pc's. Unify IS available for PC's. Contact Unisource Software at 617-491-1264/ 71 Bent Street/Cambridge, MA 02141 -- Jack Saltiel Cambridge Digital Systems {wjh12,talcott}!cdstar!saltiel "Nailed retreads to my feet and prayed for better weather."
herbie@watdcsu.UUCP (Herb Chong - DCS) (08/22/85)
In article <818@ptsfa.UUCP> jmc@ptsfa.UUCP (Jerry Carlin-4e750) writes: >There is no one 'best'. I would choose Unify if I needed a large >(say 10-250 megabyte) database, Ingres if I wanted a dbms with >all the bells and whistles and Informix if I wanted something that >also ran on pc's. just a side note. large IBM sites have single databases that are in the 100 to 200 Gbyte range and the very largest sites have databases of more than 1,000 Gbytes. do any of the unix database systems allow their data to fill more than one filesystem? does unix have the capability to handle about 20 or 30 disk drives? i know that very few people would be tempted to place such a large system onto a VAX or any kind, but are there limitations in the software also that will cause problems because of database size. Herb Chong... I'm user-friendly -- I don't byte, I nybble.... UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie CSNET: herbie%watdcsu@waterloo.csnet ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa NETNORTH, BITNET, EARN: herbie@watdcs, herbie@watdcsu
jerry@uwmcsd1.UUCP (Jerry Lieberthal) (08/23/85)
> In article <393@uwmcsd1.UUCP> jerry@uwmcsd1.UUCP (Jerry Lieberthal) writes: > > ... At any rate, for ease > >of use and non-programmability (for non-programmers) I vote for UNIFY at > >the present time. > > 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). That is precisely what I meant. I am developing some applications for production center (operations) people. It takes very little time to develope reasonabily sophisticated entry screens and reports. It also has neat C language features for those of us that need more power. But, UNIFY does have its limitations. I suppose I shouldn't complain, since it cost the University very little. I have just started to use UNIFY, so in the next few weeks I will probably be asking some questions of those of you who do use it (especially to its limit). I am also interested in UNIFY users opinions as to its good and bad points.. - jerry University Of Wisconsin-Milwaukee ihnp4!uwmcsd1!jerry
tiberio@seismo.CSS.GOV (Mike Tiberio) (08/26/85)
> more than 1,000 Gbytes. do any of the unix database systems allow their > data to fill more than one filesystem? does unix have the capability to We use symbolic links to place database directories on any file systen under a given cpu, when we get NFS, probably on any file system within our network. seismo!tiberio by the way we are the Center for Seismic Studies, we run RTI INGRES under 4.2BSD.
jmc@ptsfa.UUCP (Jerry Carlin) (08/27/85)
In article <1624@watdcsu.UUCP> herbie@watdcsu.UUCP (Herb Chong - DCS) writes: > >... do any of the unix database systems allow their >data to fill more than one filesystem? does unix have the capability to >handle about 20 or 30 disk drives? > Unify can handle up to 8 filesystems (disk drives) 8 * 256Meg (2 Gig) (it works on raw devices). -- voice= 415 823-2441 uucp={ihnp4,dual}!ptsfa!jmc
eric@osiris.UUCP (Eric Bergan) (08/29/85)
Time to add my two cents worth. A couple of years ago, I did a fairly extensive comparison of Unify and Ingres (RTI version). There seemed to be some major failings in Unify. The locking for concurrency control was insufficient, to do it correctly required the applications programmer to determine what needed to be locked. And even then, deadlock resolution was by timeout, not a more active algorithm to detect deadlock. At the time of the comparison, Unify had not implemented any kind of reliable journalling facility. This is extremely important in production applications. I do not know if they have remedied this by now. In terms of performance, Unify was faster on simple things (selects, appends, replaces), but much slower on more complex tasks, such as joins, aggregates, and projects. While it was usually twice as fast on the simple things, it was often orders of magnitude slower on the more complex transactions. This was due to the lack of a query optimizer to try and determine the most efficient query tree. Also, while Unify does provide a query language, it does not allow it to be embedded in programs. For the application developer, Unify provides function calls that implement the access methods. But note: there is no simple call to do a join, or an aggregate. As I have said, this review was done a couple of years ago, so things may have changed. I also have not looked at Informix to see how it handles these issues. Oracle, to the best of my knowledge, does provide these more advanced features, but we did not do any performance testing between Ingres and Oracle. The sales fliers for Mistress 32 also indicate that it provides these more advanced features, but I can not personally confirm or deny that claim. Basically, the bottom line again depends on what you are going to do. Unify is probably better in smaller environments, or for embedding in products that will not require much maintenance and do not support much concurrent access to data. Ingres is a better choice when building larger products, where data integrity is a bigger concern, and where the cpu and disk horsepower are more likely to be there to support it. -- eric ...!seismo!umcp-cs!aplvax!osiris!eric
eric@osiris.UUCP (Eric Bergan) (08/29/85)
> 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
jerry@uwmcsd1.UUCP (Jerry Lieberthal) (08/31/85)
> > 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 ***