Path: utzoo!attcan!uunet!husc6!bloom-beacon!gatech!mandrill!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon S. Allbery) Newsgroups: comp.databases Subject: Re: ORACLE on the cheap... questions Message-ID: <11945@ncoast.UUCP> Date: 23 Jul 88 04:23:28 GMT References: <5165@dasys1.UUCP> <8208@ncoast.UUCP> <178@turbo.oracle.UUCP> <2316@rtech.rtech.com> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.databases Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 72 As quoted from <2316@rtech.rtech.com> by davek@rtech.rtech.com (Dave Kellogg): +--------------- | In article <178@turbo.oracle.UUCP> rbradbur@oracle.UUCP (Robert Bradbury) writes | > | >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. | | I have several comments on Robert's recent posting, the least important | of which is that what he says above is simply not objectively true. +--------------- And, as I recall, there was the benchmark where they came in dead last!!! (You know, the one that led to the development of Turbo Oracle.) The real problem is that even if you use the same benchmark on all DBMSes, you may still be comparing apples to oranges. I, for one, wouldn't even consider running Informix-SQL on a large database (at least, not without Informix-Turbo). Not a flame, just an example of the fact that different DBMSes have different areas of applicability. (FilePro is even less useful on large databases -- but for small ones, it's smaller and faster than any of the big guys. You have to match the database to the task. And TP1 tells us nothing about, for example, whether Oracle or Unify will perform respectably on a document-filing database I wrote in Informix-SQL. Applicability for a specific task isn't quantifiable by a general benchmark.) +--------------- | For further information on the "DeWitt" benchmark, see the paper entitled | "Benchmarking DBMS Systems, A Systematic Approach" by Dr. David DeWitt and | (I believe now, Dr.) Dina Bitton of the University of Wisconsin. | | I will investigate the copyright on this document and see if I am able to | distribute copies to interested parties. Please send e-mail to me and I'll | let you if/when I can send you one. +--------------- SInce I'm already talking here, consider this a request. +--------------- | This "WE beat vendor X" type quote, however, disturbs me. If this continues, | and becomes standard operating procedure for this newsgroup, it could easily | mean that comp.databases will degenerate into nothing more than a forum for | vendor cross-fire. This degeneration is not unfeasible given that companies +--------------- Not as long as the aggressive user/developer-types like me are around. ;-) And I *do* mean aggressive -- there are probably *still* people at Informix who are shuddering at the bug list I handed them for Informix-SQL 1.0 (not that the bugs haven't been long fixed, but...) [36 bugs, each documented in excruciating detail, often with workarounds. The printed document was some 50 pages long] and I managed to p*ss off a few people at Data Progress last year as well. I'm currently in the process of annoying some Unify T/S types; how far that'll go will be determined by how well my copy of Accell 1.4 works when I get it. (The bug list for 1.3 is approaching the size of the Informix-SQL 1.x list -- but an indeterminate part seems to be a bug in Altos's malloc() on the 386/1000. The symptoms in Accell strongly resemble the symptoms of Jove 4.7 compiled on the beast. [NEVER run Version 1.0 of an OS!]) [You may have noticed that I'm silent on the topic of Ingres. Show me a copy for either Altos 386 or Macintosh and that'll change; I'm always willing to try out new DBMSes, but I need a copy that runs on the systems I have available to me first! --And don't talk PC to me unless it runs on an 8088; I'm not about to upgrade the miserable thing.] Okay, I'll stop terrorizing you DBMS types now. [ ;-) ] ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc