desmond@godot.UUCP (01/16/86)
Can anybody refer me to a survey of database software for UNIX systems? Better yet, can anyone recommend a package for a fairly large application on a VAX 11-750?
pavlov@hscfvax.UUCP (840033@G.Pavlov) (01/20/86)
If the goal is to settle upon a common dbms that will be effective for a wide range of applications (my assumption, since it sounds like a number of sites are involved), then I personally do not believe that either Unify or Informix is the "answer". Of current dbms's for Unix systems, I would choose Ingres or Oracle. - this is based on hands-on evaluations of 5 dbms's (including Unify, but not Informix), discussions with managers at apx. 30 sites using one or more of the dbms's mentioned above, and discussions on this net over the past 12 months. by Ingres, I mean the "commercial version", distributed by Relational Technoo- logy, Inc. greg pavlov, fstrf, amherst, ny
mo@wgivax.UUCP (01/23/86)
Look into ORACLE and SIR. Both have problems (ORACLE did not support 4.2 as of July, 1985 and SIR did not support multiple users except if everyone is interfacing through screens -- no simultaneous batch or ad hoc queries -- as of August, 1985). Informix and Unify just won't cut it for large applications, and Ingres (commercial or not) has a lot of bugs in their UNIX version (the current UNIX 4.2 port was not even able to complete the turorial outlined in the manuals without severely crashing). Ingres also requires mods to the kernel, which some (including myself) feel is a bad way to implement locking. These comments stem from an in depth evaluation of these software systems in July, 1985, including on-hands with SIR, INGRES, and INFORMIX. ORACLE did not have a version available for 4.2 at the time, and UNIFY was just too limiting. Our final decision was to keep what we had -- a Britton Lee Database Machine, the only valid solution to large database applications (500+ Mb) in the UNIX environment today (-: in my opinion, of course :-). We have since bought a second IDM. BTW: Britton Lee just announced a new "deskside" database machine for around $40,000 with disk, making it competitive with software systems. Some addresses you might find useful: Britton Lee, Inc SIR, Inc ORACLE 14600 Winchester Blvd 5215 Old Orchard Rd Los Gatos, CA 95030 Skokie, IL 60077 Menlo Park, CA (408) 378-7000 (312) 470-9770 (415) 854-7350
jmc@ptsfa.UUCP (Jerry Carlin) (01/27/86)
In article <131@wgivax.UUCP> mo@wgivax.UUCP writes: > ... Ingres also requires mods to the kernel... Actually, Ingres has a locking pseuodo device driver. I do not think that adding a "device" driver is equivalent to "mods to the kernel" since you are not changing kernel source code. -- voice= 415 823-2441 uucp={ihnp4,dual,qantel}!ptsfa!jmc
pavlov@hscfvax.UUCP (840033@G.Pavlov) (01/28/86)
>Re: Ingres very buggy on Unix machines:
I would talk to some current sites before I rejected Ingres on the basis of
that statement. We ran the same DBMS's (plus Unify and Mistress) and talked
to apx. 40-50 other sites. Our evaluation lead to the opposite conclusion;
we purchased RTI's Ingres. I do agree with the the general assessment of
Unify and Informix, however.
ed@mtxinu.UUCP (Ed Gould) (01/28/86)
>> ... Ingres also requires mods to the kernel... > >Actually, Ingres has a locking pseuodo device driver. I do not think that >adding a "device" driver is equivalent to "mods to the kernel" since you >are not changing kernel source code. There are several versions of Ingres. The current commercial version from RTI does not require kernel mods, although older versions did. The current mechanism just adds a driver. Research Ingres, running on 4.2/4.3BSD uses a user-level lock manager that communicates with the database software via a socket. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
mats@fortune.UUCP (Mats Wichmann) (01/31/86)
The version of Ingres I have seen depended on existing locking routines if they were there (as they are in many microports), but in this case you had to modify the process exit code (inside the kernel, not the stub in libc) to make sure to leave things clean. The other approach, of course, is the already mentioned "device driver". Either way, this is not very nice. Mats Wichmann Fortune Systems {ihnp4,hplabs,dual}!fortune!mats