Path: utzoo!attcan!uunet!yale!husc6!hscfvax!pavlov From: pavlov@hscfvax.harvard.edu (G.Pavlov) Newsgroups: comp.databases Subject: Re: ORACLE on the cheap... questions Message-ID: <590@hscfvax.harvard.edu> Date: 14 Jul 88 15:40:55 GMT References: <5165@dasys1.UUCP> <8208@ncoast.UUCP> <178@turbo.oracle.UUCP> Organization: Health Sciences Computing Facility, Harvard University Lines: 63 In article <178@turbo.oracle.UUCP>, rbradbur@oracle.UUCP (Robert Bradbury) writes (in response to another article): > > I *hate* statements like "wasn't too hot on the speed front". Exactly > *what* are you doing that gives you that impression? We beat Informix > and Ingres in a good percentage of the DeWitt benchmarks on a number of > machines. > A while ago I attempted to arrange a set of cooperative benchmark runs with other sites running other dbms's. The two Oracle sites I talked to claimed that their license agreements forbade publication of benchmark results. Don't know if this is completely true, but that is what I was told. The only independent comparison benchmark (Ingres, Informix, and Oracle) was a rather extensive one performed by a Palmer & Associates, Inc. (Duluth, Ga). This was performed on an IBM AT and involved apx. 130 sep- arate query or update processes. Several lines from the "executive sum- mary" of the report: "In general (using a geometric mean of normalized data approach) Ingres was from 1.63 to 2.86 times faster than Informix, and Ingres was from 10.56 to 29.00 times faster than Oracle." "Oracle was clearly outdistanced by both Ingres and Informix with 5 first place, 40 second place and 65 third place finishes." (in retrievals) "Oracle won 4 of 20 update record queries." - etc. This is not to say that this is the definitive word on these dbms's. But I have to give it more credence than the "results" that have come from the individual vendors themselves. > SQL*Report is a very old program and is being replaced with a new report > writer which is as good as anything currently on the market. The glossies and demo disk that Oracle sent me show that the new report writer is, indeed, a vast improvement over the old (comparable to the difference between a Model T Ford and a Taurus). It is also an extra- cost option. > SQL*Forms > was *NOT* designed for VMS or UNIX. It was designed to be portable across > a variety of operating systems (VM,MVS,AOS,VMS,UNIX,DOS,AEGIS,etc.) and > to do that we have our own terminal definitions. (You can support any > type of terminal you are willing to provide a terminal defninition for - > there is even a utility on UNIX systems to turn termcap definitions into > Oracle terminal definitions.) Can I ask how many menuing systems based > on termcap you have running under VM, MVS and DOS? :-) > This is also true of other multi-operating system software, including other dbms's. Some, Like Ingres, though, use the termcap syntax for this purpose, regardless of which operating system the product is running under. > The UNIX group is actively working on shrinking the time between VMS > announcement and general UNIX availabiliy. The goal for the end of > the year is a 45 day lag on primary UNIX ports and no more than a 90 > day lag for secondary UNIX ports. > Maybe the same rigorous schedule could be adopted for new Oracle product announcements ..... :-) :-) greg pavlov, fstrf, amherst, ny