Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!fernwood!oracle!news From: kbittner@oracle.uucp (Kurt Bittner) Newsgroups: comp.databases Subject: Re: Why is Oracle better than Ingres Message-ID: <1990Dec4.215711.2508@oracle.com> Date: 4 Dec 90 21:57:11 GMT References: <734@keele.keele.ac.uk> <5550@avocado20.UUCP> Reply-To: kbittner@oracle.UUCP (Kurt Bittner) Organization: Oracle Corporation, Belmont, CA Lines: 99 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." Brought to you by Super Global Mega Corp .com