tbetz@dasys1.UUCP (Tom Betz) (06/25/88)
Just today received ORACLE's offer of ORACLE-PC for $199, and ORACLE-*NIX
for $399.00, both including their SQL*Forms, Plus, Report, Calc, and Pro*C
Pre-Compiler.
This is a pretty heavy mark-down, and makes me suspicious... but also piques
my interest. It's an obvious grab for market share, but I want to inquire:
does Oracle support such things as transaction logs, roll-back and roll-forward,
the features that Zim and Progress, among others, offer?
Is it strictly an SQL, or does it have some of the richness of functions
available with Progress, and to a greater extent, with Zim?
Responses appreciated... if sufficient, will summarize to the Net.
--
Tom Betz
ZCNY {bellcore,cmcl2}!cucard!dasys1!tbetz
Yonkers, NY, USA 10701-2509
"Opinions? What opinions? These are >facts<!!"allbery@ncoast.UUCP (Brandon S. Allbery) (07/03/88)
As quoted from <5165@dasys1.UUCP> by tbetz@dasys1.UUCP (Tom Betz): +--------------- | Just today received ORACLE's offer of ORACLE-PC for $199, and ORACLE-*NIX | for $399.00, both including their SQL*Forms, Plus, Report, Calc, and Pro*C | Pre-Compiler. | | This is a pretty heavy mark-down, and makes me suspicious... but also piques | my interest. It's an obvious grab for market share, but I want to inquire: | does Oracle support such things as transaction logs, roll-back and roll-forward, | the features that Zim and Progress, among others, offer? | | Is it strictly an SQL, or does it have some of the richness of functions | available with Progress, and to a greater extent, with Zim? +--------------- The only restriction in the $199/$399 version is in the license: you can only use it for development, to use it as a "live" system you have to fork over the rest of the full price. --But, judging from how many people pay for "shareware" programs, I daresay that in practice people use it as if they had a full license anyway. (I do *not* advocate doing so, I'm merely making an observation.) Oracle has rollback, rollforward, and transaction logs. The version I used (5.1) wasn't too hot on the speed front (watch, however, for Turbo Oracle) and SQL*Forms and SQL*Report are miserable compared to tools designed for Unix (they both act like what they are: designed for VMS -- and they are therefore lacking in flexibility Unix types take for granted, such as support for multiple terminals/printers). The SQL supports quite a few more functions than (say) Informix or Unify, but not as many as Progress. Nor can new functions be linked into SQL. (Oracle, if you're listening, this would be a big help!!! So would (a) making multiple terminals w/graphics in SQL*Forms work and (b) releasing that new SQL*ReportWriter for more than just VMS.) -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
rbradbur@oracle.UUCP (Robert Bradbury) (07/09/88)
In article <8208@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes: > > The only restriction in the $199/$399 version is in the license: you can > only use it for development, to use it as a "live" system you have to fork > over the rest of the full price. --But, judging from how many people pay > for "shareware" programs, I daresay that in practice people use it as if > they had a full license anyway. (I do *not* advocate doing so, I'm merely > making an observation.) > The $199/$399 customers are also not entitled to upgrades. Soooo when version 6 comes out they will have to pay if they want the latest and greatest. > > Oracle has rollback, rollforward, and transaction logs. The version I used > (5.1) wasn't too hot on the speed front (watch, however, for Turbo Oracle) > and SQL*Forms and SQL*Report are miserable compared to tools designed for > Unix (they both act like what they are: designed for VMS -- and they are > therefore lacking in flexibility Unix types take for granted, such as > support for multiple terminals/printers). 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. The functionality of a full-function RDBMS (transaction logs, security, rollback, roll-forward, read-consistancy, etc.) imposes a certian amount of overhead. You cannot compare the performance of database systems which have those features with those that do not. 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. 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? :-) > > The SQL supports quite a few more functions than (say) Informix or Unify, > but not as many as Progress. Nor can new functions be linked into SQL. Well, you in fact can add functions to SQL if you know what tables to modify and can relink the kernel. We have customers who are running with special functions. The problem with this is that it requires shipping an Oracle link kit (I assume you have megabytes of disk space to spare :-)) and it results in a support nightmare ("oh, you added these functions and your database is now corrupted... hmmm, you don't think it could be the functions you added do you?") > (Oracle, if you're listening, this would be a big help!!! So would (a) > making multiple terminals w/graphics in SQL*Forms work and (b) releasing > that new SQL*ReportWriter for more than just VMS.) We do listen, you have to realize though that the marketplace we are trying to serve is not just the UNIX marketplace. SQL*FORMS will work with multiple terminal types if you provide the terminal description. 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. I would expect your sales person could do some investigation and come up with an availability date for SQL*ReportWriter on UNIX. -- Robert Bradbury Oracle Corporation (206) 784-9474 hplabs!oracle!rbradbur
davek@rtech.rtech.com (Dave Kellogg) (07/13/88)
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. I have neither seen a published report nor participated in any formal benchmark that would confirm his claim of DeWitt superiority. In fact, I've never participated in any informal benchmark that would confirm his claim, either. More important, however, are the two brief notes below. A Note on Standards ------------------- Just as the TP1 "standard" is elusive, so is the "DeWitt" (or Wisconsin) benchmark. In the case of TP1, vendors select whatever pieces of the well- defined DebitCredit benchmark that suit them, and call that TP1. In the case of DeWitt, vendors tend to select whatever subset of queries of the DeWitt test that suits them, and call that the "DeWitt" benchmark. There are two points which should be noted here. First, I am not suggesting that Robert's firm has used a DeWitt subset, as I am not familliar with their tests. Second, and more important, I am neither suggesting nor do I believe that there is anything inheritantly wrong with DeWitt subsets or TP1 tests (which are essentially DebitCredit subsets). DebitCredit is a tough benchmark which tests a system for a large number of factors that are important in Online Transaction Processing. TP1 tests, on the other hand, generally test only for basic transaction throughput against fairly small databases. However, this is not a question of good vs. evil as long as one *recognizes* the differences between the tests and is not mislead into mistaking a test for its distant cousin. The same argument holds true for DeWitt subset "X" vs. DeWitt subset "Y". Different benchmarks test different things, and in general, those different things bear little resemblance to any user's actual reality. Bearing this in mind could prove quite useful, as I expect the coming months to bring a barrage of numbers from all the various DBMS vendors. 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. A Note On "The Net" ------------------- I have always enjoyed comp.databases as an open, unpolluted forum for both users of commercial database products and any persons interested in DBMS systems. From time to time users may express displeasure with a given system (no major vendor has failed to be victimized in the last year or so), and the vendors have either remained silent, offered explanations, or posted re- markably unbiased postings on the technical issues regarding their products. I might add also, that I have always enjoyed Robert's postings for this same candor. 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 like Relational Technology, Informix, and Oracle employ literally thousands of people, and each could easily place a designated "net monitor" to fire back accusations at the other vendors. A little inter-vendor "teasing" is probably inevitable, but that's where I think it should stop. Cluttering the net with "WE beat so-and-so" will neither reward the readers of this group, nor, in actualitly, any given DBMS vendor. David Kellogg +-------------------------------------------------------------------------- | Relational Technology (INGRES) New York City | (212) 952-1400 ...!ucbvax!mtxinu!rtech!davek | | The above opinions are merely my own and should not be | construed as any official statement of Relational Technology +--------------------------------------------------------------------------
gupta@cullsj.UUCP (Yogesh Gupta) (07/14/88)
In article <2316@rtech.rtech.com>, davek@rtech.rtech.com (Dave Kellogg) writes: > > 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. > Benchmarking DBMS Systems, A Systematic Approach by Dr. Dave DeWitt, Univ. of Wisconsin Dr. Dina Bitton, currently at Cornell Univ. Dr. Carolyn Turbyfill, currently at Sun Microsystems Just setting the record straight. -- Yogesh Gupta | If you think my company will let me Cullinet Software, Inc. | speak for them, you must be joking.
pavlov@hscfvax.harvard.edu (G.Pavlov) (07/14/88)
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
DMasterson@cup.portal.com (07/15/88)
In message <2316@rtech.rtech.COM>, davek@rtech.rtech.COM writes: >A Note on Standards >------------------- >[much deleted on "hard-to-follow" benchmark standards] Perhaps its time that the various DBMS vendors used one of the yearly symposiums on DBMSs to sit down and agree on an understandable benchmark that everyone can handle and that has some meaning (you don't have to test everything about a DBMS for the benchmark to have meaning). Perhaps this test could be broken up into subparts (user interface, 4GL processing, SQL integrity vs. ANSI, relational capabilities vs. Codds rules, distributed capabilities vs. Date's rules, performance per query type, thru-put, etc.) >A Note On "The Net" >------------------- >[much deleted on Net and comp.databases etiquette] True. The rule for this area should be "vendor - defend thyself, but don't pick on the other guy"! >David Kellogg > >+-------------------------------------------------------------------------- >| Relational Technology (INGRES) New York City >| (212) 952-1400 ...!ucbvax!mtxinu!rtech!davek >| >| The above opinions are merely my own and should not be >| construed as any official statement of Relational Technology >+-------------------------------------------------------------------------- David Masterson ^-^ DMasterson@cup.portal.com (@v@) (The opinions above are not \_/ necessarily those of this station) =^=^=
greggy@infmx.UUCP (greg yachuk) (07/16/88)
In article <590@hscfvax.harvard.edu>, pavlov@hscfvax.harvard.edu (G.Pavlov) writes: > 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. This is indeed true. We (here at Informix) were unable to publish our benchmarks versus Oracle because of this very license agreement. There are ways around it, though. You just have to be sneaky (but fully legal)! > greg pavlov, fstrf, amherst, ny Greg Yachuk Informix Software Inc., Menlo Park, CA (415) 322-4100 {uunet,pyramid}!infmx!greggy !yes, I chose that login myself And they offered us a roof above our heads And like fools we beleived every last word they said. -- The Christians
deal@kodak.UUCP (Stephen M. Deal) (07/16/88)
Greg -
As much as you tried to introduce some objectivity into the
comparison of DBMS products, someone will undoubtly bring
up some facts that you left out. Examples are: What version
of each product was used? Did all of the products run on the
exact same machine or did one of the products require more
than 640k? :-)
In my book, benchmarks aren't worth anything unless:
a) All the products are run on the SAME machine.
b) Each product runs the same set of transactions.
c) Each vendor is permitted to tune their own product.
Oh yes, how many applications REALLY require 50+ TPS?
BTW, in a recent (~May, 1988) issue of Digital Review they discussed
the predominant VAX/VMS RDBMSs. What I found interesting is that
in the editorial of that issue DR states that DR Labs
has been trying to benchmark Oracle for some time. The
reason that they haven't done it (or published results if they have)
is for the same reason that you gave, Oracle will not allow
benchmarks to be published.
Perhaps the reasoning is that the benchmark might be done improperly
and produce erroneous results. Evidently Relational Technology took
the risk and agreed to a benchmark of INGRES and INGRES/STAR.
I would hope that DR continues to produce benchmarks on products
using identical machines and transactions.
--
Steve Deal UUCP: ..rutgers!rochester!kodak!deal
Disclaimer: "Everyone is entitled to their own opinion,
the above is mine and not that of my employer."rbradbur@oracle.UUCP (Robert Bradbury) (07/16/88)
In article <590@hscfvax.harvard.edu>, pavlov@hscfvax.harvard.edu (G.Pavlov) writes: > In article <178@turbo.oracle.UUCP>, rbradbur@oracle.UUCP (Robert Bradbury) writes (in response to another article): > > > > > 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. This is true. The license agreement prohibits publication of benchmark results. One reason for this is that some vendors will publish results comparing apples with oranges and not make it completely clear to the user. A benchmark was done last year at a Silicon Valley computer manufacturer (who shall remain nameless); Unify later packaged and started publishing these numbers showing it as having much faster insert rates than the other RDBMS (without pointing out the much lower level interface it was using to perform these inserts -- yes, Virginia; we can append records to the database file faster than other people can parse and execute SQL statments... :-) ). Oracle threatened UNIFY with legal action due to the violation of the license agreement and UNIFY has since that time stopped publishing the numbers. At the same time I heard some rumor that Informix was taking Oracle to court involving "restraint of trade" involving this license clause. Yes, YOUR RDBMS dollars are paying lawyers to play these games. sigh. > > 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. This is *EXACTLY* the type of thing I was refering to in my original posting. You *fail* to mention the versions which were being compared in this benchmark. Oracle, Informix and Ingres have had a history of leapfrogging each other in performance benchmarks over the last 5 years. If you take production releases at one point in time you get one set of results; at another point in time you get another set. You don't mention what operating system the benchmark was performed on, what the system configuration was, how much time was spent tuning the systems, etc. And of course numbers from a PC AT are generalizable to VAXes, Suns, Sequents, etc. :-) I'd suggest you contact our UNIX marketing dept and request results for a recent benchmark done at PACBELL. As Oracle was picked over the other vendors one would probably presume that the benchmark results were not as bad as the study you are quoting. I appreciate the comments that we do not want this to decay into a we-beat-so-and-so on the following tests debate. At the same time I as an individual who has spent many long nights running these benchmarks in competitive situations (and in the early days losing many of them) get a little testy when people present a picture of Oracle's performance which reflects past history more than current reality. I will agree that DeWitt/TP1 tests give a very narrow view of DBMS performance and that given differences in the various systems involved that it is difficult to make reasonable comparisons. The bottom line is that if you want to know how your application will perform on these systems YOU MUST BENCHMARK YOUR APPLICATION. And even then I'll bet that in a good percentage of the cases I can take your best efforts and beat the application, RDBMS and operating system with a stick and make your initial results look fairly silly. (This is not to say that you don't know what you are doing, just that I haven't seen a benchmark yet where a clever person couldn't bend the results significantly.) As an example of how poor benchmarking efforts are I'll make the statement that no one who has ever benchmarked RDBMS systems on UNIX has ever bothered to verify which RDBMS really guarantee that when you commit your transaction the data is physically on the disk. (I'm sure I'll get some comments on this - :-)). I make that statement because in 5 years of benchmarking comparisons no one has ever told me they knew how to monitor system calls or go in and examine the UNIX FILE table to determine blocks were being written through the cache to the disk. The best they usually do is unplug the machine to see if the database got corrupted -- sorry folks but that doesn't provide *proof* unless you do it a few thousand times when you are executing 30 transactions a second. Oracle in fact lost a number of benchmarks over the years because other vendors were ignoring the issue of data integrity. > 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. > Oracle has responded to customer requests to divide products up into seperatly priced items so you don't have to pay for things you don't need. (the flip side of that coin is that you get to pay more for all the things you do need.) > Some, Like Ingres, though, use the termcap syntax for this purpose, > regardless of which operating system the product is running under. Given how difficult TERMCAP is to maintain I wouldn't consider this a plus. AT&T converted to TERMINFO to make it faster; they missed the boat though because terminal descriptions belong in a database. Sorry this turned out so long but I like to try and present a balanced view of things. A current Oracle employee (former RTI employee) told me recently that he used my rather candid comments about Oracle's less than stellar performance a few years ago to RTI's great advantage in some sales situations. Now that I think the situation is more even you can be sure that I'm going to make point of pointing out any holes in any performance claims. Of course I can't say whether or not this reflects the opinions of Oracle's management (most of them don't know what to do with me). -- Robert Bradbury Oracle Corporation (206) 784-9474 hplabs!oracle!rbradbur
pavlov@hscfvax.harvard.edu (G.Pavlov) (07/18/88)
In article <296@infmx.UUCP>, greggy@infmx.UUCP (greg yachuk) writes: [ re Oracle's licensing agreement forbidding publication of benchmark results ] > > .................... We (here at Informix) were unable to publish our > benchmarks versus Oracle because of this very license agreement. There > are ways around it, though. You just have to be sneaky (but fully legal)! > ... such as Cullinet's recent ad re VAX dbms's (last seen in June 20 Digital review, pages 64-65). This one presents four of those little compari- son tables, comparing IDMS/SQL, Oracle, Ingres, and Rdb. The dbms's are named in three of them and all are in the same order in each. In the 4th, "transaction processing speed", Cullinet's competitors are called "vendor x, vendor y, vendor z". One would assume that the same order was used in the transaction table as in the others. If this is the case, then Oracle is the slowest of the four. On the other hand, since Oracle would logically be seen as Cullinet's biggest competitior, then there is a chance that the order was shuffled, and the "slowest" is not really Oracle....... ad nauseum... greg pavlov, fstrf, amherst, ny
pavlov@hscfvax.harvard.edu (G.Pavlov) (07/18/88)
In article<180@turbo.oracle.UUCP>, rbradbur@oracle.UUCP(Robert Bradbury) writes: > ....... The [Oracle] license agreement prohibits publication of benchmark > results. One reason for this is that some vendors will publish results > comparing apples with oranges and not make it completely clear to the user. > [ followed by an example and several legal maneuvers stemming from this issue] > > Yes, YOUR RDBMS dollars are paying lawyers to play these games. sigh. > Actually, the majority of the RDBMS dollars paid to the large vendors is spent on marketing, no ? In Oracle's case (if I interpreted the last annual statement sent me), this was in the 70% of total revenue range ??? Sounds insane, so maybe not. Robert objects to the benchmark summary that I quoted: > > This is *EXACTLY* the type of thing I was refering to in my original > posting. You *fail* to mention the versions which were being compared > in this benchmark. Oracle, Informix and Ingres have had a history of > leapfrogging each other in performance benchmarks over the last 5 years. > ..... You don't mention what operating system the benchmark was performed > on, what the system configuration was, how much time was spent tuning the > systems, etc...... Yet, rereading Robert's summary of Oracle's benchmark claims, I could not find any of the above information either. I also have not seen anything to substantiate "... a history of leapfrogging each other..." > > ........... The bottom line is that > if you want to know how your application will perform on these systems > YOU MUST BENCHMARK YOUR APPLICATION. .............. > How true. But, from what I've seen, not done often enough. The number of selections based solely on "analyses" of vendor-supplied material, hearsay, and (even) quantity of advertising is astounding. > > ........ And even then I'll bet that > in a good percentage of the cases I can take your best efforts > and beat the application, RDBMS and operating system with a stick and > make your initial results look fairly silly........... > Also true but if I have done my homework, then it shouldn't matter. I will be the one programming/designing my database and applications and in general, I will take the long view and look at what I can achieve without being too clever. greg pavlov, fstrf, amherst, ny
aland@infmx.UUCP (Dr. Scump) (07/19/88)
: Brandon Allbery: | Oracle has rollback, rollforward, and transaction logs. The version I used | (5.1) wasn't too hot on the speed front (watch, however, for Turbo Oracle) : Robert Bradbury, Oracle: | From rbradbur@oracle.UUCP@munnari.oz Fri Jul 8 16:19:35 1988 | Date: 8 Jul 88 23:19:35 GMT | References: <5165@dasys1.UUCP> <8208@ncoast.UUCP> | Organization: ORACLE Corporation, Belmont CA, USA | | 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. The functionality of a full-function RDBMS (transaction logs, | security, rollback, roll-forward, read-consistancy, etc.) imposes a | certian amount of overhead. You cannot compare the performance of | database systems which have those features with those that do not. So, what is the implication here -- that the other products lack these features? How about some support for this claim? What is a "good percentage of" DeWitts? How many is "a number of machines" (and out of how many in the overall sample)? : Dave Kellogg, Relational Tech: | From: davek@rtech.rtech.com (Dave Kellogg) | Newsgroups: comp.databases | Subject: Re: ORACLE on the cheap... questions | Date: 13 Jul 88 03:33:41 GMT | References: <5165@dasys1.UUCP> <8208@ncoast.UUCP> <178@turbo.oracle.UUCP> | (Excellent comment on standards and benchmarks and their | pitfalls omitted) | | | A Note On "The Net" | ------------------- | | 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 | like Relational Technology, Informix, and Oracle employ literally thousands of | people, and each could easily place a designated "net monitor" to fire back | accusations at the other vendors. | A little inter-vendor "teasing" is probably inevitable, but that's where | I think it should stop. Cluttering the net with "WE beat so-and-so" will | neither reward the readers of this group, nor, in actualitly, any given | DBMS vendor. | | David Kellogg Amen. : G Pavlov, Harvard U. | From: pavlov@hscfvax.harvard.edu (G.Pavlov) | Subject: Re: ORACLE on the cheap... questions | 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 | | 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. | : Stephen Deal, Kodak | From: deal@kodak.UUCP (Stephen M. Deal) | Subject: Re: ORACLE on the cheap... questions | Date: 16 Jul 88 01:58:01 GMT | References: <5165@dasys1.UUCP> <8208@ncoast.UUCP> <178@turbo.oracle.UUCP> <590@hscfvax.harvard.edu> | Organization: Eastman Kodak Co, Rochester, NY | | In my book, benchmarks aren't worth anything unless: | a) All the products are run on the SAME machine. | b) Each product runs the same set of transactions. | c) Each vendor is permitted to tune their own product. I would add d) Or, NO vendor is allowed to do application- or benchmark- specific testing (as the user would likely experience in a real-world situation) and e) Similar products are compared (e.g. compiled vs. compiled, interpreted vs. interpreted, closest match of capabilities) Now, for the fun part. : Robert Bradbury, Oracle | From: rbradbur@oracle.UUCP (Robert Bradbury) | Subject: Re: ORACLE on the cheap... questions | Summary: Benchmarks and environmental information | Date: 16 Jul 88 04:25:26 GMT | References: <5165@dasys1.UUCP> <8208@ncoast.UUCP> <178@turbo.oracle.UUCP> <590@hscfvax.harvard.edu> | Organization: ORACLE Corporation, Belmont CA, USA | | In article <590@hscfvax.harvard.edu>, pavlov@hscfvax.harvard.edu (G.Pavlov) writes: | > In article <178@turbo.oracle.UUCP>, rbradbur@oracle.UUCP (Robert Bradbury) writes (in response to another article): | > > | > > | > 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. | | This is true. The license agreement prohibits publication of benchmark | results. One reason for this is that some vendors will publish results | comparing apples with oranges and not make it completely clear to the user. NO KIDDING!!! Did you happen to miss the ads Oracle ran in UNIX WORLD for the better part of the year "comparing" Oracle and Informix? | ... | Yes, YOUR RDBMS dollars are paying lawyers to play these games. sigh. Come on! Just who started this benchmark "game", anyway? | > (Quotes the Palmer & Associates benchmarks again) | | This is *EXACTLY* the type of thing I was refering to in my original | posting. You *fail* to mention the versions which were being compared | in this benchmark. Oracle, Informix and Ingres have had a history of | leapfrogging each other in performance benchmarks over the last 5 years. | If you take production releases at one point in time you get one set of | results; at another point in time you get another set. You don't mention | what operating system the benchmark was performed on, what the system | configuration was, how much time was spent tuning the systems, etc. | And of course numbers from a PC AT are generalizable to VAXes, Suns, | Sequents, etc. :-) NO KIDDING! I think you will have a tough time defending this position to anyone who has seen your ads in UNIX WORLD. (For example, the June '88 issue, page 10). This ad claims to depict a "benchmark" in which Oracle claims a resounding performance victory over Informix. Some highlights: 1) regarding your gripe about "you *fail* to mention what versions were being compared in the benchmark": in this ad, you run Oracle 5.0 (current version) against Informix version 2.0. Version 2.0 is OVER TWO YEARS OLD. The current version for OVER A YEAR before this ad ran was 2.10.00 (now 2.10.03 is current). There were also 3 other releases in between, including a major enhancement release (2.00.05) which came out in December *86*. 2) Informix-TURBO is displayed in the ad photo, implying that the "benchmarks" were run against TURBO, which was NOT TRUE. TURBO did not exist in the version listed as benchmarked. (I just dare ya to let an independent run a legit benchmark of Oracle vs. Turbo). 3) The ad states that the benchmark is an "industry standard" benchmark, but DOES NOT NAME IT. It doesn't even name the PRODUCTS used; it could have been compiled embedded SQL against an interpreted ACE report, for all the ad says. 4) The ad photo depicts a 3B2, although the benchmark was supposedly run on a Sun, implying that the performance stats apply to their "fire sale" 3B2 port. | ... | As an example of how poor benchmarking efforts are I'll make the | statement that no one who has ever benchmarked RDBMS systems on | UNIX has ever bothered to verify which RDBMS really guarantee that | when you commit your transaction the data is physically on the disk. | (I'm sure I'll get some comments on this - :-)). I make that statement | because in 5 years of benchmarking comparisons no one has ever told me | they knew how to monitor system calls or go in and examine the UNIX | FILE table to determine blocks were being written through the cache to the | disk. The best they usually do is unplug the machine to see if the database | got corrupted -- sorry folks but that doesn't provide *proof* unless | you do it a few thousand times when you are executing 30 transactions | a second. --------------- -------- Won't touch that one... | | Oracle in fact lost a number of benchmarks over the years because | other vendors were ignoring the issue of data integrity. Ah, now to the new ad campaign. Integrity. You forget that UNIX from the outset handled writes asynchronously for cooked devices -- I doubt that any vendor really "ignored" this situation. This is part of the reason why several vendors came out with raw i/o capability, I suppose. Recently, some versions support forced writes (via the O_SYNC flag in System V and O_WSYNCH in XENIX), but this is new. The O_SYNC flag doesn't even show up in AT&T's printed System V Programmer's Manual Volume 2 (? - I'm at home, I think it's volume 2. The one on system calls.) My copies, anyway :-]. Besides, the real issue in the transaction logging methods with which I am familiar (4 vendors encompassing UNIX, MVS, and VM, not including Oracle, so this may not apply to Oracle) is whether the write completed to the *transaction log*, not the database. In the implementations I know, the data on disk is essentially trashed by the recovery process; the most recent backup is copied over the data and all committed transactions are reprocessed against the backup, beginning from the backup or a checkpoint. (Or, the transactions after the checkpoint are removed, then reprocessed from the log in one other implementation; I never did really understand that one). The funniest thing is that they choose the Suns to run their benchmarks. Sun 3.X machines DO NOT SUPPORT synchronous writes anyway (no O_SYNC flag here, folks), so any claim that their benchmarks are hurt by "integrity issues" on these machines is BOGUS. The only way to force i/o is to use raw devices; Oracle decries raw devices as being "complex" in their current ad. (If my understanding of Sun 3.X synchronicity is wrong, I will post a followup and apology. I confirmed this with a friend at Sun about a month ago). The current ads do *not* indicate that this integrity claim applies only to certain (e.g SVR2+) ports, that I recall. | Sorry this turned out so long but I like to try and present a balanced | view of things. Oh? :-] Mine also turned out longer that I expected or wanted, but I wanted to present another side. Now that everyone has been heard from, can we take any further discussion to email? Thanks. I speak strictly for myself and not Informix; I am solely responsible for any inaccuracies. | Robert Bradbury | Oracle Corporation | (206) 784-9474 hplabs!oracle!rbradbur -- Alan S. Denney | Informix Software, Inc. | {pyramid|uunet}!infmx!aland Disclaimer: These opinions are mine alone. If I am caught or killed, the secretary will disavow any knowledge of my actions. Santos' 4th Law: "Anything worth fighting for is worth fighting *dirty* for"
davek@infmx.UUCP (David Kosenko) (07/19/88)
In article<180@turbo.oracle.UUCP>, rbradbur@oracle.UUCP(Robert Bradbury) writes: > > ........... The bottom line is that > if you want to know how your application will perform on these systems > YOU MUST BENCHMARK YOUR APPLICATION. .............. > Be careful here - you are assuming that the end-user has a single application that can be benchmarked. When this is the case, fine. But often, a DBMS is purchased without knowing in advance everything for which it will be used. There may be many, many applications that will be developed using this product, some of which were not even dreamed of at evaluation time. Also, the applications can be very, very different in structure. In cases such as these, it becomes impossible to benchmark your application. This leaves the person in charge of making a purchase decision dependent upon general benchmark results for performance evaluation. Must dash - Dave -- Disclaimer: The opinions expresses herein are by no means those of Informix Software. "But a man's reach should exceed his grasp or what's a heaven for ?"
eric@pyrps5 (Eric Bergan) (07/20/88)
In article <302@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes: > >NO KIDDING! >I think you will have a tough time defending this position to anyone who >has seen your ads in UNIX WORLD. (For example, the June '88 issue, page >10). This ad claims to depict a "benchmark" in which Oracle claims a >resounding performance victory over Informix. Just to add a little fuel to the fire... The latest ComputerWorld (dated July 18th) has a two page Informix ad. In it, it compares revenues for Informix, Oracle, and INGRES, presumably in some segment of the UNIX marketplace. I'll leave this graph to the financial people. But it also includes a bar graph of "Informix", "Competitor #1", and "Competitor #2", which is labeled a TP1 benchmark study, and labels the y axis "transactions per second", without any actual numbers. Informix is shown to be about 2.5 times competitor #1 and 2 times competitor #2. >Some highlights: > 1) regarding your gripe about "you *fail* to mention what versions > were being compared in the benchmark": in this ad, you run Oracle > 5.0 (current version) against Informix version 2.0. Version 2.0 > is OVER TWO YEARS OLD. The current version for OVER A YEAR before > this ad ran was 2.10.00 (now 2.10.03 is current). There were also 3 > other releases in between, including a major enhancement release > (2.00.05) which came out in December *86*. Ditto for the new Informix ad. No mention of what versions of any of the products. > 3) The ad states that the benchmark is an "industry standard" benchmark, > but DOES NOT NAME IT. It doesn't even name the PRODUCTS used; it > could have been compiled embedded SQL against an interpreted ACE > report, for all the ad says. Ditto for the new Informix ad. No mention of what products were used. > 4) The ad photo depicts a 3B2, although the benchmark was supposedly run > on a Sun, implying that the performance stats apply to their "fire > sale" 3B2 port. Ditto for the new Informix ad. No mention of what platform was used for the test results. The point I am trying to make is that I don't think you should necessarily hold an individual employee of a company responsible for their ad campaigns unless that person actually did provide the copy for the ad, or approved it. Certainly a one or two page ad is not going to contain the same level of depth that a performance brief would have. Yes, I would like to see some more reality injected into the benchmark wars, but given their very nature, I don't think that is going to happen in the near future. Nor is it something new - look at the current DEC/IBM war over IBM's RAMP-C benchmark - that fight has been going on for several years. Could we please tone down the attacks in this group? If you want to post performance briefs on tests on your respective products, I think all of us would like to read them. But holier than thou arguments really don't get us anywhere. We all know that there are benchmarks that Informix wins, others that Oracle wins, others that INGRES wins, others that Sybase wins, ... Further, each of the products is constantly evolving and improving both functionality and performance. I work with the R&D and porting groups at most of the database companies, and believe me, there are definite strong points to each of the DBMS's. There are also weak points, and in every case that I know of, the vendor is aware of these and working on improving it. We now return you to the your regularly scheduled show, "Battle of the Database Benchmarks".
rbradbur@oracle.UUCP (Robert Bradbury) (07/21/88)
In article <597@hscfvax.harvard.edu>, pavlov@hscfvax.harvard.edu (G.Pavlov) writes: > Actually, the majority of the RDBMS dollars paid to the large vendors is > spent on marketing, no ? In Oracle's case (if I interpreted the last annual > statement sent me), this was in the 70% of total revenue range ??? Sounds > insane, so maybe not. This is an accurate statement. Oracle's R&D expenditures have been running between 13% and 10% of revenues over the last 3 years. Microsoft's were 11% last year. Even semiconductor houses (which one would expect to have to have very high R&D expenditures) rarely get over 25%. Of course given the way annual reports are laid out non-R&D expenditures can only fall into 3 other areas: cost of goods, sales & marketing, general and admin overhead. The cost of goods is very low in the software business and general and admin overhead is less than 10% in any company I've looked at. That means that most software companies spend a lot of money on sales and marketing. Of course this isn't all going to pay lawyers. I suspect that Oracle's legal staff is quite a bit smaller than AT&T's UNIX licensing staff (:-)) even though we probably have more contracts to deal with. Part of the "marketing" expense is involved in educating the D.P. community on things like standards (SQL), portability and connectability. It also goes to pay for those great little ads with Oracle F-14's shooting down Ashton Tate biplanes. The "sales" expense goes into maintaining regional offices in most major cities (to provide pre-sales technical support and education centers where you can take a course in how to use the product). Also included are the expenses of all the trade shows (Comdex, UniForum, etc.) I'm amazed myself at how much companies have to spend to promote their products but I think that is a reflection of the world we live in. > > Robert objects to the benchmark summary that I quoted: > > > > This is *EXACTLY* the type of thing I was refering to in my original > > posting. You *fail* to mention the versions which were being compared > > in this benchmark. Oracle, Informix and Ingres have had a history of > > leapfrogging each other in performance benchmarks over the last 5 years. > > ..... You don't mention what operating system the benchmark was performed > > on, what the system configuration was, how much time was spent tuning the > > systems, etc...... > > Yet, rereading Robert's summary of Oracle's benchmark claims, I could not > find any of the above information either. I also have not seen anything to > substantiate "... a history of leapfrogging each other..." Touche. I will have to see what I can come up with to back up these claims. I suspect that the hard numbers I need to back it up are covered by a non-disclosure agreement of some sort. I make the claim based on the fact that the sort/merge/join modifications made to Oracle 5.0 were done specifically to outperform earlier releases of Informix and Ingres which had been improved to outperform Oracle 4.0. One place to start is UNIX Review June '88 pg 4 where a benchmark done on a Sun 3/160 using Oracle version 5.0 and Informix version 2.0 has Oracle doing a select of 1000 rows, a projection of 10000 rows, summed 100 groups and selected 100 groups in less time than Informix could select the first 1000 rows. Now I believe these are all DeWitt queries but I'll have to do some research to be sure. If the Informix guys are on their toes I suspect they have a response to this. -- *** All of the above is my opinion only. Reader's discretion is advised. *** Robert Bradbury 206-784-9474 Oracle Corporation hplabs!oracle!rbradbur
pavlov@hscfvax.harvard.edu (G.Pavlov) (07/21/88)
In article <302@infmx.UUCP>, aland@infmx.UUCP (Dr. Scump) writes: > > Quoting RTI's Dave Kellogg: >> ....companies like Relational Technology, Informix, and Oracle employ >> literally thousands of people, and each could easily place a designated >> "net monitor" to fire back accusations at the other vendors. Isn't this already the case (not just dbms vendors) ? How should one in- terpret the appearance of solitary net "users" from very large companies, usually technically astute, but whose "contributions" invariably boost his/her company's products and with few exceptions denigrates com- petitors' ?? "fire back" misses the boat - I would say that the real dam- age is usually accomplished much more subtly and "professionally". greg pavlov, fstrf, amherst, ny
dror@infmx.UUCP (Dror Matalon) (07/23/88)
In article <599@hscfvax.harvard.edu> pavlov@hscfvax.harvard.edu (G.Pavlov) writes: >In article <302@infmx.UUCP>, aland@infmx.UUCP (Dr. Scump) writes: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Quoting RTI's Dave Kellogg: >>> ....companies like Relational Technology, Informix, and Oracle employ >>> literally thousands of people, and each could easily place a designated >>> "net monitor" to fire back accusations at the other vendors. > > Isn't this already the case (not just dbms vendors) ? How should one in- > terpret the appearance of solitary net "users" from very large companies, > usually technically astute, but whose "contributions" invariably > boost his/her company's products and with few exceptions denigrates com- > petitors' ?? "fire back" misses the boat - I would say that the real dam- > age is usually accomplished much more subtly and "professionally". > > greg pavlov, fstrf, amherst, ny Greg, Aland (Alan Denny), who posts most of the Informix info, does it on his own and with no support from the company. I suspect that Robert Bradbury does the same for Oracle, and others for RTI. I suspect that most of these people , do it on their own because they care about their companies. The last benchmark wars did get a little out of hand, but I seriously doubt that these were a result of corporate strategy to "subtly and professionally denigrate competitors." About a year ago somebody from RTI explained why something that was thought of as a bug in our product, was a result of the Relational Model, and couldn't be solved in any of the products on the market !!! So at least in this news group I don't think things are that bad. Dror Dror Matalon Informix Software Inc. {pyramid,uunet}!infmx!dror 4100 Bohannon drive Menlo Park, Ca. 94025 415 322-4100 The opinions expressed here Are of mine and probably Do not reflect Informix Software Inc.
allbery@ncoast.UUCP (Brandon S. Allbery) (07/23/88)
We seem to have some misunderstandings and some time lags here. . . . As quoted from <178@turbo.oracle.UUCP> by rbradbur@oracle.UUCP (Robert Bradbury): +--------------- | In article <8208@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes: | > Oracle has rollback, rollforward, and transaction logs. The version I used | > (5.1) wasn't too hot on the speed front (watch, however, for Turbo Oracle) | | 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 +--------------- Informix 3.3 (which is a good deal faster than that miserable SQL product that Roger Sippl is now trying to cram down our throats!) and Unify were my benchmarks. Admitted, neither does the full set of rollback/rollforward and transaction logs -- but Unify does two of them with little speed penalty. I could see rollback implemented on top of the existing facility with little trouble, and in fact the functions are provided to do this oneself "manually" by opening the transaction log. +--------------- | 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. SQL*Forms +--------------- And, at about the time I was writing my original message, it came out for SunOS. Now for 6.0 and SQL*ReportWriter for Altos -- I told them I'd evaluate it for them when it came out. +--------------- | Oracle terminal definitions.) Can I ask how many menuing systems based | on termcap you have running under VM, MVS and DOS? :-) +--------------- I was thinking more of the graphics. Accell IDS and Informix-4GL both keep the graphics in the terminal definitions (termcap in both cases); I saw nothing to prevent your keeping character graphics in the Oracle terminal descriptions -- but you force me to use separate screens for separate terminal types instead. When I have to support a client which has a random mixture of Altos III's, Altos V's, and Wyse 50's, that is totally unacceptable. +--------------- | > The SQL supports quite a few more functions than (say) Informix or Unify, | > but not as many as Progress. Nor can new functions be linked into SQL. | | Well, you in fact can add functions to SQL if you know what tables to modify | and can relink the kernel. We have customers who are running with special +--------------- Then you need a more compact version of the link kit, perhaps. I know of at least one client that would benefit from having transcendental functions in SQL... as it turns out, I'm working in C linked into RM/COBOL instead (ugh!). +--------------- | to serve is not just the UNIX marketplace. SQL*FORMS will work with | multiple terminal types if you provide the terminal description. +--------------- But I have to declare three different screens to use on terminals with three different character graphics sequences!!! PLEASE add character graphics to the terminal description and use generic characters in the screens! It's not all that difficult -- Accell does it all the time. Oh, yeah -- while I have you by the ear [ ;-) ] ... The 386- and PC-flavored market you've expanded into isn't a big one for designing one's own front-ends, so SQL*Forms really needs to be overhauled to make it more generally functional. Problems I've had with it include: * Using the "select/sort" option in the block definition can get one into big trouble if one adds a constraint on a field (say, to perform upshifting on a query) -- I set up something along the lines of (working from memory, the Oracle manuals are 30 miles from here and it's midnight...): [prompt is "WHERE:"] MYTABLE.MYFIELD = UPCASE(':SOMEFIELD') This worked UNLESS there was a single quote in the field, at which point the SQL interface threw a fit and scared the sh*t out of the data entry operator. Why is the :FIELD expression a text substitution instead of a binding? * Certain useful operations aren't possible, due to the separation of user-initiated operations and database updates. (KEY-NXTREC != NXTREC) This resulted in gobs of hooks on KEY-* and *still* didn't execute my hook everywhere it was needed. (I don't remember what the exact problem was; I can try to restore the backup onto my personal system and reproduce it. I *do* remember that I couldn't get the following to work: in English, "after query go to next block, query 'detail' records, and return". In fact, there were a few examples in the SQL*Forms manual that, typed into a form exactly as printed, produced errors.) Sometimes I wish I could take all the good parts of all the DBMSes I've worked with and roll them up together into a single good DBMS. It's painfully obvious from the user's (and developer's) standpoint that DBMSes have quite a bit of maturing to do. (That's not really a flame, I can't realistically expect a DBMS to show up "fully-formed and wearing the latest style hat" -- it's just frustrating to be aware of the limitations and not be able to do anything about it. Such is the price of the exponential rate of software development, as seen from my vantagepoint.) ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
allbery@ncoast.UUCP (Brandon S. Allbery) (07/23/88)
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
allbery@ncoast.UUCP (Brandon S. Allbery) (07/29/88)
As quoted from <180@turbo.oracle.UUCP> by rbradbur@oracle.UUCP (Robert Bradbury): +--------------- | (who shall remain nameless); Unify later packaged and started publishing | these numbers showing it as having much faster insert rates than the other | RDBMS (without pointing out the much lower level interface it was using | to perform these inserts -- yes, Virginia; we can append records to the | database file faster than other people can parse and execute SQL statments... | :-) ). Oracle threatened UNIFY with legal action due to the violation of +--------------- Why? Because they were right? I'm currently discussing this with an Informix TS type. Frankly, whatever supposed benefit you get from SQL is lost when you have to pass character SQL statements down a pipe or through shared memory to be parsed at runtime and then get the data back the same way. (PIPE_TWO_TASK: is miserable. But at least you ship FAST_TWO_TASK: with the kernel: to get the equivalent in Informix one must buy Informix-Turbo.) Not only is Unify's (and Informix 3.3's) database updating low level, but (in the case of Unify) the ESQL is translated _at_compile_time_ into the same low-level C code... which makes for blinding speed compared to runtime parsing of complex grammars. (Network hooks aren't that difficult, either, Unify has had UNIPROC for quite a while now. It passes requests, but *not* in the form of ASCII grammars.) Do not make the assumption that people will accept loss of speed in return for a *little* more portability. A bytecode network interface is just as amenable to an ANSI standard as SQL is, and it's faster because it doesn't need to be parsed and the statements end up being smaller anyway. +--------------- | This is *EXACTLY* the type of thing I was refering to in my original | posting. You *fail* to mention the versions which were being compared | in this benchmark. Oracle, Informix and Ingres have had a history of | leapfrogging each other in performance benchmarks over the last 5 years. +--------------- I would *love* to bench Informix 3.3 against Oracle based on this statement. Maybe I will (of course I can't publish the results, but it should be interesting nonetheless). --Certainly an application that had been running in 3.3 for years slowed down abruptly when moved into Oracle.... (Again, SQL parsing and shipping data through (pipes|shared memory) has disastrous effects on speed. I expect Informix-SQL is no better.) +--------------- | a recent benchmark done at PACBELL. As Oracle was picked over the other | vendors one would probably presume that the benchmark results were not | as bad as the study you are quoting. +--------------- We implemented the *same* application on the *same* machine in *four* DBMSes. I don't think you want to hear the results, and neither will Informix because they shatter a few of Mr. Sippl's cherished myths. It is this which provided the objective proof of what I had noticed on my own previously (i.e. SQL is less efficient than low-level access). I should like to try it in a few others as well and see what happens; there are other considerations in the use of SQL than just the need to parse it at runtime. +--------------- | many of them) get a little testy when people present a picture of Oracle's | performance which reflects past history more than current reality. +--------------- But the future of the DBMS is, quite frankly, *slower* then the past. At least, so far; and while you can speed up the hardware to compensate the older DBMSes will be ported to that new hardware and keep its lead. +--------------- | if you want to know how your application will perform on these systems | YOU MUST BENCHMARK YOUR APPLICATION. And even then I'll bet that | in a good percentage of the cases I can take your best efforts | and beat the application, RDBMS and operating system with a stick and | make your initial results look fairly silly. (This is not to say +--------------- ...don't forget to look at the interface as well. I tossed the Progress Test Drive after trying to build some screens that turn out to be trivial in both Accell/Generator and SQL*Forms. In that case, speed is worthless if you can't figure out how to implement the application in the first place. (Note that recent releases of Progress are supposed to have a screen generator in them, so this argument may or may not still apply). Progress's frame handling language -- a language similar to SQL in style -- is just another nail in the coffin of those language types; it's perfectly possible to be non-procedural without being opaque. (Informix Ace, Unify RPT and Accell/ Language, and the database access code -- not involving frame descriptions -- of Progress are good examples of this brand of "semi-non-procedural" code which gets the benefits of non-procedural code without the flaws.) +--------------- | > Some, Like Ingres, though, use the termcap syntax for this purpose, | > regardless of which operating system the product is running under. | | Given how difficult TERMCAP is to maintain I wouldn't consider this | a plus. AT&T converted to TERMINFO to make it faster; they missed the | boat though because terminal descriptions belong in a database. +--------------- It *is* in a database. So what if it's hierarchical instead of relational? And the problem with using a relational DBMS for this is that nobody will be bothered to design a simple DBMS that can be standard Unix; instead we're all having C-ISAM shoved down our throats. (A simple B-tree library and intermediate-level database routines have been posted to comp.sources.misc; if someone with a bit more savvy in B-trees wants to finish implementing the delete code we wouldn't need to license the database from someone else. Termcap, after all, doesn't exactly need to be blazingly fast at -- or even capable of -- TP1.) Just stirring up the hornet's nest. . . . ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc