Re: Comparison of DB2 and Oracle?

michael newport wrote:

> correction you thought that you had made your point...
>
> You can also use JAVA on Ingres.

But nothing I've read says you can use Java IN Ingres. As in stored procedures. But since Ingres is missing triggers, I suppose it doesn't really matter. (Have to admit the rough counterpart - events - is neat. A bit like database level triggers.)

>
> 1. Security model – same

Agreed, if you restrict yourself to simple grants. The Oracle security model has a few additional things that are relevant and somewhat more advanced than what the Ingres DBA manual indicates. At the tip of the iceberg we see Virtual Private Database ...

> 2. Scalability - same

I can't seem to find any reference to scalability in the Ingres documentation, or to system limitations. Nor did Google give any references to big Ingres implementations.

Pointers would be appreciated to indicate that Ingres can handle 3000 concurrent users and 20TByte of raw data.

> 3. Performance - same

Checked TCP.org - no Ingres in sight. Any suggestions?

> 4. Shared Everything Architecture - equivalent
> 5. RAC - equivalent

So you are saying I can have 2 servers updating the same database concurrently? Not SMP - separate machines. Updating the same table?

Couldn't find that in the docco.

What I did find, in the System Administrator's guide (pp11-1) is "The Ingres High Availability Option is not scalable; that is, it does not provide active instances on multiple nodes."

> 6. DataGuard - equivalent

I simply could not find the terms failover and failback in the docco. Pointer?

The System admin manual does discuss a cluster-coordinated switch over, using scripts. I assume you mean that. A bit like the pre-DataGuard 'Fail Safe' back in 7.3.4 and 8.0.

> 7. RMAN - equivalent

Nothing I saw in the docco indicated that there is a facility to do the backupand track the location of the pieces of the backups to provide recommendations about which files (Journal or other) are required to recover the database. Seems it's a manual effort. Perhaps I'm wrong?

> 28. TAF (transparent application failover) - equivalent

That's usually a function related to the cluster-cordinate failover. TAF can provide transparent failover, with no need to restart the transaction.

> 8. User defined indexes - same

We store non-traditional datatypes (keyword, spatial data, images, music, sheet music ....) and want to create a custom index? Oracle permits that - you define the indexing mechanisms and tell Oracle to use that WHILE keeping the base integrity of the index mechanism.

Ingres, being open source, allows you to totally rewrite indexing - so that is the same. However, the engine doesn't then guarantee the integrity of other kinds of indexes while one is putzing with the base indexing code. A bit of a trade-off?

> 9. User defined operators - same
> 10. User defined locking - nice but never needed

Most developers depend on table serialization to ensure that operations block appropriately. Even if that cuts scalability to 5-10 concurrent users.

I prefer having some mechanism other than data locking to coordinate concurrent operations.

> 11. Domain indexes - nice but never needed

Domains are basically previously undefined datatypes, somewhat like UDTs (which are not limited to just "structures")

Why would anyone want to create any new data type and create an index type that's relevant to the UDT? Much better to put that code in the application than in the database! (Not)

> 12. Reverse-key indexes - same

Didn't see that in the online SQL manual as part of the CREATE INDEX command. Have to take your word for it.

> 13. Compressed indexes - same

Yup. Finally one that seems similar. With the level of flexibility described, possibly even better than Oracle's compression.

> 14. Function based indexes - nice but never needed

I think you missed the definition. In Oracle, the index is based on a user defined _expression_ - so the ability to create an index on

        (col1 * col2 + col3 )

is permitted. This are useful if the expression (using any function, even user created functions) happens to occur frequently. Why look up the pieces and assemble them later?

I could go on, but ....

My conclusion now is the same as I'd concluded that early 90's when a buddy went to work for Ingres and encouraged a 'fair evaluation': Ingres is a good database for reasonably plain, small, simple database usage with nicely defined data buckets. For that it's probably one of the better databases, but from what I can tell all effort goes into the application to overcome the limitations.

However, my philosophy is 'give unto the database everything that can be centralized'. Oracle's philosophy of additional tools, tricks and simplifications help me. They will optimize and maintain those leaving me free to worry about the application. And since I am willing to use them, these items make the application's 3-year cost fairly reasonable.

I'm happy that Ingres is Open Source, even under CA's 'special' license. (I hate it when the lawyers have to add value to a perfectly reasonable GPL.)

Of all the Open Source RDBMSs, I think Ingres will give Oracle the biggest run for it's money if it survives. However I see MySQL, PostgreSQL - and now Ingres - are competing and I think that will likely devolve to the old unix SysV vs BSD core battles which helped no one (except Microsoft).

Since the questions I asked were mainly rhetorical, hopefully this will end the "Ingres is good too!" contribution to the DB2 vs Oracle thread. <G>

/Hans Received on Sat Oct 23 2004 - 07:14:26 CEST