csb19@seq1.kl.ac.uk (K. Allen) (11/28/90)
Could someone outline the major differences between Oracle and Ingres. Please state if you are using the commercial or university versions of Ingres. If you can objectively summerise the advantages of Oracle over Ingres or visa versa then I would be grateful.
rad@genco.bungi.com (Bob Daniel) (11/29/90)
In article <734@keele.keele.ac.uk> csb19@seq1.kl.ac.uk (K. Allen) writes: >Could someone outline the major differences between Oracle and Ingres. >Please state if you are using the commercial or university versions >of Ingres. > I work with Oracle, not Ingres but know someone using Ingres. Oracle recovers very well from crashes where I hear Ingres can completely crash the database if the system crashes. Ingres seems to be more 'developer' friendly than Oracle's SQL Forms 3.0. If you are developing entirely in C and not using a front end, Oracle is a very nice database engine. I give Oracle's database engine an 'A'. SQL Forms 3.0 isn't entirely bad depending on the application your writing. I've worked with better front ends though (4th Dimension on Mac).
mhunt@pbs.org (12/01/90)
In article <142@genco.bungi.com>, rad@genco.bungi.com (Bob Daniel) writes: > In article <734@keele.keele.ac.uk> csb19@seq1.kl.ac.uk (K. Allen) writes: > >In article <734@keele.keele.ac.uk> csb19@seq1.kl.ac.uk (K. Allen) writes: >>Could someone outline the major differences between Oracle and Ingres. >>Please state if you are using the commercial or university versions >>of Ingres. >> > >I work with Oracle, not Ingres but know someone using Ingres. Oracle >recovers very well from crashes where I hear Ingres can completely >crash the database if the system crashes. In the seven years that I've worked with commercial versions of Ingres, I have never lost any data due to a system crash. I will say that prior to Ingres 6.0, database inconsistencies may have occurred as a result of a crash. However, I never experienced a situation where I could not recover the database using the Ingres RECOVERDB utility. > >Ingres seems to be more 'developer' friendly than Oracle's SQL Forms 3.0. >If you are developing entirely in C and not using a front end, Oracle is a >very nice database engine. I give Oracle's database engine an 'A'. SQL Forms >3.0 isn't entirely bad depending on the application your writing. I've >worked with better front ends though (4th Dimension on Mac). It's true that Ingres is 'developer' friendly, which will usually result in more productive developers and friendlier end-user applications. I think that it's a little impractical to pay a considerable amount of money for RDBMS and not make use of its developer's toolkit (SQL*Forms). Along with providing a extremely powerful database engine, Ingres' Visual Forms Editor (VIFRED) is a comprehensive and easily understood method of developing the front-ends for your applications. Other Ingres options worth noting: Knowledge Management o Rules o Stored DB Procedures Object Management o User-Defined Data Types (UDTs) - Allows you to develop your own abstract datatypes that can be used in your applications like any of the standard Ingres datatypes. o User-Defined Functions (UDFs) - Allows you to develop functions that can be linked to the Server and used with SQL statements. -- mhunt@pbs.org
palat@motcid.UUCP (Mohan Palat) (12/01/90)
csb19@seq1.kl.ac.uk (K. Allen) writes: >Could someone outline the major differences between Oracle and Ingres. >Please state if you are using the commercial or university versions >of Ingres. >If you can objectively summerise the advantages of Oracle over Ingres >or visa versa then I would be grateful. Briefly .... Oracle has a more extensive implementation of SQL than Ingres. Ingres supports QUEL and SQL (in Ingres 5, the SQL implementation is incomplete). Oracle's 4GL (SQL*Forms) is incomplete in its functionality whereas Ingres' 4GL (ABF) provides a more complete environment for rapid applications development. Oracle uses an unusual process architecture (in UNIX). Several processes have to be started up before one can even access a database. Ingres does not require any such initialization. Oracle provides a wider set of utility packages (most of which have names that start with SQL*) than Ingres. The task of determining which packages/modules are needed for an application is therefore more complicated in Oracle. Ingres has a wider choice of data storage methods(heap, hash, isam, b-tree) than Oracle(b-tree, clustered). Unlike Ingres, Oracle is not a "natural" UNIX dbms in that it was not developed on UNIX and is more popular in the IBM and DEC non-UNIX environments. It is highly compatible with IBM's DB2. Mohan Palat
pavlov@canisius.UUCP (Greg Pavlov) (12/02/90)
In article <142@genco.bungi.com>, rad@genco.bungi.com (Bob Daniel) writes: > In article <734@keele.keele.ac.uk> csb19@seq1.kl.ac.uk (K. Allen) writes: > >Could someone outline the major differences between Oracle and Ingres. > >Please state if you are using the commercial or university versions > >of Ingres. > > > > I work with Oracle, not Ingres but know someone using Ingres. Oracle > recovers very well from crashes where I hear Ingres can completely > crash the database if the system crashes. > The only sources from which I "heard" the above is Oracle marketing reps and Oracle ads (tho those were aimed at everyone else's UNIX DBMSs in general). We have used INGRES for apx. 6 years and have experienced our share of system crashes. Whatever faults INGRES may have, database corruption due to system crashes has never been one of them. . greg pavlov, fstrf, amherst, ny pavlov@stewart.fstrf.org
dlw@odi.com (Dan Weinreb) (12/02/90)
In article <5550@avocado20.UUCP> palat@motcid.UUCP (Mohan Palat) writes:
Oracle uses an unusual process architecture (in UNIX). Several
processes have to be started up before one can even access a
database. Ingres does not require any such initialization.
Is this really a practical drawback to Oracle? That is, can't the
startup of these processes be arranged to be completely transparent
and automatic?tilman@netcom.UUCP (Tilman Spokert) (12/03/90)
In article <1990Dec2.080257.21343@odi.com> dlw@odi.com writes: >In article <5550@avocado20.UUCP> palat@motcid.UUCP (Mohan Palat) writes: > > Oracle uses an unusual process architecture (in UNIX). Several > processes have to be started up before one can even access a > database. Ingres does not require any such initialization. > This message, and the previous one (...never lost any data because of crash...) must be talking about pre-INGRES 6. INGRES 6 is now a server architecture, and you have to start 4+ processes before anything goes. Sometimes these processes don't start because of a previous crash (like everything was hosed, so you had to kill the dbms server...), and you are left with an un-accessible database. The manual says "This should not happen, call Tech-Support if it happens". Haha. We had to do that twice in the last couple of month, and they give you two options: - Restore from the last backup or checkpoint - Take the risk of having screwed-up data and "force" the database to be marked as consistent again. As they say "please check all your records carefully...". Very nice, indeed. >Is this really a practical drawback to Oracle? That is, can't the >startup of these processes be arranged to be completely transparent >and automatic? Not practical. With INGRES 6.3 on a Sun4, we either have a dead (hanging) process or a core dump from one of them at least once a day. Requires manual intervention to get them going again. -- Tilman Sporkert, apple!netcom!tilman or tilman@netcom.uucp - I don't need a Nintendo. I got a SparcStation... -
chris@vision.UUCP (Chris Davies) (12/04/90)
In article <5550@avocado20.UUCP> palat@motcid.UUCP (Mohan Palat) writes: > Oracle uses an unusual process architecture (in UNIX). Several > processes have to be started up before one can even access a > database. Ingres does not require any such initialization. In version 6.x of both Ingres and Oracle (and Informix/Turbo too) you need 3 or 4 processes running as daemons before you can access any database. This situation is not just true for Oracle. Please check your facts before posting! In article <1990Dec2.080257.21343@odi.com> dlw@odi.com writes: > Is this really a practical drawback to Oracle? That is, can't the > startup of these processes be arranged to be completely transparent > and automatic? Correct. Unless the system crashes _badly_ you do not need to worry about these background processes. IMHO Ingres seems to handle crash recovery slightly better than Oracle - but that's only a superficial view. I don't know why these background processes are required - but when comparing the two versions of Informix (normal and "turbo") the one with daemons goes like the clappers (relative to the other version). Chris -- VISIONWARE LTD | UK: chris@vision.uucp JANET: chris%vision.uucp@ukc 57 Cardigan Lane | US: chris@vware.mn.org BANGNET: ...!ukc!vision!chris LEEDS LS4 2LE, England | VOICE: +44 532 788858 FAX: +44 532 304676 -------------- "VisionWare: The home of DOS/UNIX/X integration" -------------
swfc@cs.columbia.edu (Shu-Wie F Chen) (12/05/90)
The original question: Why is Oracle better than Ingres? After reading all the follow-ups, I have reached this conclusion: Oracle is not better than Ingres. *swfc -- ------------------------------------------------------------------------------- Shu-Wie F Chen Columbia University Department of Computer Science swfc@cs.columbia.edu 500 W120th Street, New York, NY 10027
mdchaney@bronze.ucs.indiana.edu (M Darrin Chaney) (12/05/90)
In article <1338@vision.UUCP> chris@vision.UUCP (Chris Davies) writes: >In article <5550@avocado20.UUCP> palat@motcid.UUCP (Mohan Palat) writes: >> Oracle uses an unusual process architecture (in UNIX). Several >> processes have to be started up before one can even access a >> database. Ingres does not require any such initialization. > >In version 6.x of both Ingres and Oracle (and Informix/Turbo too) you need 3 >or 4 processes running as daemons before you can access any database. This >situation is not just true for Oracle. Please check your facts before posting! Ingres 6.x has 6 processes that run detached, at least under VMS. These are necessary to do database access, as well as handle internode communication, synchronization, etc. Also, it usually creates a subprocess when someone runs Ingres. This really isn't some big, bad thing, IMHO. Darrin mdchaney@iubacs mdchaney@bronze.ucs.indiana.edu mdchaney@rose.ucs.indiana.edu
kbittner@oracle.uucp (Kurt Bittner) (12/05/90)
In article <5550@avocado20.UUCP> palat@motcid.UUCP (Mohan Palat) writes: >csb19@seq1.kl.ac.uk (K. Allen) writes: > >>Could someone outline the major differences between Oracle and Ingres. and ... > Mohan Palat writes: > [... text deleted ...] > Oracle's 4GL (SQL*Forms) is incomplete in its functionality > whereas Ingres' 4GL (ABF) provides a more complete environment > for rapid applications development. When making statements like this, please help the rest of the net out by telling us how Oracle is incomplete, and which version you are talking about. Making blanket comments like this without stating your rationale is misleading at best. In my experience in consulting engagements and sales situations, we have been able to implement far more robust applications in equivalent or less time than have the folks from Ingres. Now I'm sure Ingres consultants have the same sorts of stories, so at the very least we are better on some things and they are better on others. The version is *highly* relevant, since SQL*Forms v3 is FAR superior to SQL*Forms v2. Enough flames on this one. Also, there is a need to contrast rapid application development from production application development. In many cases, applications can be prototyped very rapidly, up to the point where the application development environment hits the wall (dictating switching from ABF to Ingres/4GL). SQL*Forms provides a consistent environment for prototyping through production application develop- ment. > Oracle uses an unusual process architecture (in UNIX). Several > processes have to be started up before one can even access a > database. Ingres does not require any such initialization. There is nothing unusual about architecting the database as a set of co- operating processes. Actually, it provides much better scalability across multiple processors than databases architected on a single monolithic process which controls all db access. Also, it provides better memory utilization and concurrency control than an architecture which links all db code into the user's process. The real issues are in the areas of concurrency, throughput, performance, locking, read-consistency, distributed capabilities, etc. > Oracle provides a wider set of utility packages (most of which > have names that start with SQL*) than Ingres. The task of determining > which packages/modules are needed for an application is therefore more > complicated in Oracle. Having choices is always more difficult. On the other hand, having a set of tools, where each tool is well suited to the task at hand is IMHO better than having a general purpose tool (ala swiss army knife) that does many things but only a few well. Having more products is neither bad nor good, depending on their merit. > Ingres has a wider choice of data storage methods(heap, hash, isam, > b-tree) than Oracle(b-tree, clustered). Warning: flames ahead. In limited cases (read "benchmarks" or very specialized applications) heap and hash can be useful but require very careful application management as well as intimate knowledge of data distribution (hash) and memory resources usage (heap). I'm not sure where ISAM is preferable to b+tree, but there may be some. In most cases, however, heap and hash are just not worth the pain of managing them. (Donning carcinogenic asbestos suit: I prepare to stand corrected if anyone can provide real-world examples of where other access methods have proven useful.) > Unlike Ingres, Oracle is not a "natural" UNIX dbms in that it was > not developed on UNIX and is more popular in the IBM and DEC non-UNIX > environments. It is highly compatible with IBM's DB2. Most of Ingres' sales are in VMS and not UNIX. The base-port of a product has nothing to do with the amount of engineering that goes into porting the database. Actually, a tremendous amount of work goes into porting the product to all the diverse flavors of UNIX. The RDBMS code itself is divided into generic code (logical db functions) and OS-specific code. Generic code is going to be the same no matter what the platform (a row is a row is a row), while OS-specific code needs to deal with physical things like memory, disk I/O, semaphores, latches, etc. In other words, the base port can be developed anywhere, but each port must be engineered to take advantage of the best features of each platform. UNIX is still not UNIX is still not UNIX, because of proprietary enhancements each hardware vendor has added to their OS. ------------------- General Comments ---------------------- In general, the net is a great forum for sharing experiences and ideas. Many times however, opinions are stated as facts, without explaining how you reached that conclusion. You may find Oracle's (or Ingres' or Sybase's, etc.) products wonderful or horrible or anything in between, but let people know why. Only then are your comments valuable; otherwise it is too easy to dismiss them as flaming. Kurt Bittner Consultant - Oracle Corporation kbittner@oracle.com "My comments are my own and do not reflect those of my employer."
ph@cs.uow.edu.au (Rev Phil Herring, DD (Ret.)) (12/05/90)
In article <SWFC.90Dec4111746@mendelssohn.cs.columbia.edu> swfc@cs.columbia.edu writes: > >The original question: Why is Oracle better than Ingres? > >After reading all the follow-ups, I have reached this conclusion: > >Oracle is not better than Ingres. Maybe, maybe not... I've benchmarked ORACLE and Ingres for a slightly odd application (a realtime control system with *very* high insertion rates), and ORACLE was over ten times faster than Ingres in that case. (In fact, only ORACLE could handle the high insertion rate with full DBMS fucntionality - the only other product that came close was Sybase, and it required an unlogged "bulk copy" operation to manage that. This causes me to believe that ORACLE is actually kinda quick for an RDBMS.) This is, of course, just one way in which one is "better" than the other. If you count reliability, customer support, development and CASE tools, etc, you will get a totally different picture. -- Phil.
davek@informix.com (David Kosenko) (12/06/90)
In article <1338@vision.UUCP> chris@vision.UUCP (Chris Davies) writes: > >In version 6.x of both Ingres and Oracle (and Informix/Turbo too) you need 3 >or 4 processes running as daemons before you can access any database. This >situation is not just true for Oracle. Actually, Informix-Turbo and Informix-OnLine require only 1 daemon process (tbinit) "before you can access any database". An engine process (sqlturbo) is also started when you begin database access, but it is not technically a daemon as it exists in a 1 to 1 relationship with a front end process (and goes away when the front end does). There are some additional daemon processes that are optionally run, but they are not needed before database access can occur. >Please check your facts before posting! Always a wise policy. Dave Kosenko Informix Client Services -- Disclaimer: These opinions make no sense and should be ignored! ************************************************************************** The heart and the mind on a parallel course, never the two shall meet. -E. Saliers
davidm@uunet.UU.NET (David S. Masterson) (12/06/90)
>>>>> On 4 Dec 90 21:57:11 GMT, kbittner@oracle.uucp (Kurt Bittner) said: > ------------------- General Comments ---------------------- > In general, the net is a great forum for sharing experiences and ideas. > Many times however, opinions are stated as facts, without explaining how you > reached that conclusion. You may find Oracle's (or Ingres' or Sybase's, > etc.) products wonderful or horrible or anything in between, but let people > know why. Only then are your comments valuable; otherwise it is too easy to > dismiss them as flaming. I just wanted to say that I think this (and the rest of the cited article) was a very even-handed way for someone working for a vendor to defend their product without getting religious about it and causing more harm than good. On the net, at least, it is much nicer to see people from the various vendors (who may or may not be vendor representatives) honestly try to make things better rather than get into the "my product is better than your product" wars. Not enough people say that, so I thought I would. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
rob@linkers.med.utah.edu (Rob Sargent) (12/06/90)
In article <SWFC.90Dec4111746@mendelssohn.cs.columbia.edu> swfc@cs.columbia.edu writes: > >The original question: Why is Oracle better than Ingres? > >After reading all the follow-ups, I have reached this conclusion: > >Oracle is not better than Ingres. Maybe, maybe not... I've benchmarked ORACLE and Ingres for a slightly odd application (a realtime control system with *very* high insertion rates), and ORACLE was over ten times faster than Ingres in that case. (In fact, only ORACLE could handle the high insertion rate with full DBMS fucntionality - the only other product that came close was Sybase, and it required an unlogged "bulk copy" operation to manage that. This causes me to believe that ORACLE is actually kinda quick for an RDBMS.) This is, of course, just one way in which one is "better" than the other. If you count reliability, customer support, development and CASE tools, etc, you will get a totally different picture. -- Phil. Was that comparison done using straight SQL or embedded with 3GL?
dhepner@hpcuhc.cup.hp.com (Dan Hepner) (12/06/90)
>ORACLE was over ten times faster than Ingres in that case.
All major DBMS vendors, including Oracle, are regularly plagued
by such reports.
The default assumption, as supported by many cases, is that
the slow system can be made to perform at something like the
speed of the fast one. This may take some cleverness, or
may take some configuration modification not well explained
by the vendor, but it can almost always be done.
Dan Hepner
Not a statement of Hewlett-Packard Company.pavlov@canisius.UUCP (Greg Pavlov) (12/06/90)
In article <1990Dec4.215711.2508@oracle.com>, kbittner@oracle.uucp (Kurt Bittner) writes: > When making statements like this, please help the rest of the net out by > telling us how Oracle is incomplete, and which version you are talking about. > .... The version is *highly* relevant, since > SQL*Forms v3 is FAR superior to SQL*Forms v2. Enough flames on this one. > Inevitably, when I see "oracle" in a message header relating to features, I know that the message itself will begin with some variant of "{ have you seen | are you talking about | we will have this in } Version X" The problem here is that, regardless of what one compares that exists on his or her platform TODAY, Oracle has either announced or will eventually port to it something better. But the latter, at least, is true of every other vendor. And most of us have to deal with TODAY. Enough flames on this one.... > > > Ingres has a wider choice of data storage methods(heap, hash, isam, > > b-tree) than Oracle(b-tree, clustered). > > [.....flame re value of the above.... ] > (Donning carcinogenic asbestos suit: I prepare to stand corrected if anyone > can provide real-world examples of where other access methods have proven > useful.) > Given that Oracle will not legally permit customers to publish test results comparing its products to others, I think you know that you can leave the suit off. Oracle can "publish" "results", but I guess that's because its more objective than we are :-) Re an example: actually, we just moved a table from a b-tree structure to what INGRES calls "compressed heapsort" and created a set of secondary index- es into it. Why ? the move saved a rather large amount of space, by our standards: the table has apx. 700,000 rows; retrieval on any indexed field is fast enough (within a second most of the time, depending on load, etc) for interactive use; and large batch runs using large chunks of the table - 300K records and up - are faster and put less of a load on our server since its cpu is a hell of a lot faster than its disks. This isn't your typical application (it's an oddball one for us) but we do run across "oddballs" often enough that having physical structure flexibility is useful. > > Most of Ingres' sales are in VMS and not UNIX. "most" being more than 50% . Actually, "commercial" INGRES originated on VMS, using a "research" version from BSD, and it was at least several years before it went back to UNIX. pavlov@stewart.fstrf.org
ph@cs.uow.edu.au (Rev Phil Herring, DD (Ret.)) (12/07/90)
In article <2060006@hpcuhc.cup.hp.com> dhepner@hpcuhc.cup.hp.com (Dan Hepner) writes: >>ORACLE was over ten times faster than Ingres in that case. > >All major DBMS vendors, including Oracle, are regularly plagued >by such reports. I *did* point out the circumstances of the test (very high insert rate). I also pointed out that this was a rather odd example. >The default assumption, as supported by many cases, is that >the slow system can be made to perform at something like the >speed of the fast one. This may take some cleverness, or >may take some configuration modification not well explained >by the vendor, but it can almost always be done. The vendors were all involved. They were given specs and wrote their own benchmark programs. The only exceptions were Oracle and Informix - I wrote their test programs. I can only assume, therefore, that the Ingres people knew how to make their system run as fast as it could, and that they did their best. By the way, I didn't try to tweak ORACLE to the limit. The database was pretty much "out of the box". -- Phil.
marti@mint.inf.ethz.ch (Robert Marti) (12/07/90)
In article <ROB.90Dec5145443@linkers.med.utah.edu> rob@linkers.med.utah.edu (Rob Sargent) writes: > Maybe, maybe not... I've benchmarked ORACLE and Ingres for a slightly > odd application (a realtime control system with *very* high insertion > rates), and ORACLE was over ten times faster than Ingres in that case. I think we all should disregard this statement, since -- to the best of my knowledge -- the Oracle licence does not allow the publication of performance measurements ;-) Robert Marti | Phone: +41 1 254 72 60 Institut fur Informationssysteme | FAX: +41 1 262 39 73 ETH-Zentrum | E-Mail: marti@inf.ethz.ch CH-8092 Zurich, Switzerland |
tim@ohday.sybase.com (Tim Wood) (12/11/90)
In article <76172@iuvax.cs.indiana.edu> mdchaney@bronze.ucs.indiana.edu (M Darrin Chaney) writes: >In article <1338@vision.UUCP> chris@vision.UUCP (Chris Davies) writes: >>In article <5550@avocado20.UUCP> palat@motcid.UUCP (Mohan Palat) writes: >>> Oracle uses an unusual process architecture (in UNIX). Several >>> processes have to be started up before one can even access a >>> database. Ingres does not require any such initialization. >> >>In version 6.x of both Ingres and Oracle (and Informix/Turbo too) you need 3 >>or 4 processes running as daemons before you can access any database. This >>situation is not just true for Oracle.... >Ingres 6.x has 6 processes that run detached, at least under VMS. These are >necessary to do database access, as well as handle internode communication, >synchronization, etc. Also, it usually creates a subprocess when someone >runs Ingres. > >This really isn't some big, bad thing, IMHO. > It may become a bad thing under load. Dedicated processes can become bottlenecks. It's also instructive to count up how much memory the service processes occupy, and divide that among all concurrent users (plus each individual user's DBMS process) to get the per-user memory usage. The more memory a user's representation to the DBMS requires, the less memory will be available for caching database objects. Also, it is more likely that paging will occur. We've found that with large amounts of memory per user, performance tends to suffer under moderate-to-large user load. Of course, one can always scale up the machine running the DBMS, but all other things being equal, less memory per user will yield better price/performance. -TW Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim Dis claim er dat claim, what's da difference? I'm da one doin da tawkin' hea.
ph@cs.uow.edu.au (Rev Phil Herring, DD (Ret.)) (12/18/90)
A short time ago I posted some comments regarding the relative merits of various RDBMSs. Some people have elected to take those comments rather more seriously than I believe they should. So, in fairness to them, I would like to point out to the readers of this newsgroup that benchmark information is, of course, notoriously difficult to assess, and simply quoting numbers out of the blue (as I did) does not constitute anything other than meaningless *rumour*, unless it is accompanied by detailed background information. My comments were not accompanied by such details, and so they should be treated as (at best) the unsubstantiated opinion of one individual. -- Phil.