Path: utzoo!attcan!telly!problem!compus!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!news.cs.indiana.edu!rutgers!ub!canisius!pavlov From: pavlov@canisius.UUCP (Greg Pavlov) Newsgroups: comp.databases Subject: Re: Why is Oracle better than Ingres Message-ID: <3059@canisius.UUCP> Date: 6 Dec 90 04:12:20 GMT References: <734@keele.keele.ac.uk> <5550@avocado20.UUCP> <1990Dec4.215711.2508@oracle.com> Organization: Canisius College, Buffalo N.Y. 14208 Lines: 51 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 Brought to you by Super Global Mega Corp .com