Re: how do we rate and compare DB's? sybase vs oracle vs informix, etc.

From: Rick Gebethner <gebethner_at_intranet.ca>
Date: 1996/12/16
Message-ID: <593uea$3o4_at_news.intranet.ca>#1/1


hkon_at_world.std.com (Henry B Kon) wrote:

>In the book crossing the chasm about high tech marketing, the author
>suggests that inferior technology oftens beat superior technology, and
>gives the example among others of oracle beating sybase on marketing
>not on technology.
 

>How do these two companies compare? Are there real differences in the
>product capabilities? Is one company inherently more or less capable
>than another? Can we predict long term which company will win?
 

>How do we rate databases overall anyway?
 

>performance, multi-platform, distributed transaction capability, tools, etc?
 

>is there anywhere a master "list of features"?
 

>thanks,
 

>H the Kkonmeister

Henry,

Twice now, I've been involved in a DBMS selection for a large organization. It is not a trivial exercise. Nor is there a single way to rate the products.

I would suggest that you start with listing your organizational requirements. You might want to start with things such as,

What will the DBMS be primarily used for (ie. OLTP, DDS, object repository)?
What volumetrics can you forsee (ie. number of concurrent users, data volumes)?
What hardware and OS will you use?
Is high or low end scalability a requirement? Do you expect to run the DBMS on multiple platforms? What is/will be your data architecture (ie. centrallized, fragmented, replicated, etc)?
What front end tools, systems management and monitoring tools do you expect to leverage into the new dbms?
Do you have licencing and support advantages, based on your current technical environment, to go with one vendor or another?

The list goes on...

Largely the big DBMS manufacturers all produce good products (or bad products, depends who you talk to). A fair bit of leapfrogging goes on as one vendor or another puts out a new version. Largely disregard that.

Focus on:

Fit within you organization,

Whether the DBMS is available on the hardware and OSs you will use, and whether these are strategic platforms for the vendor (as opposed to being released late in the DBMS life cycle - ie. Sybase on O/S2),

Whether the DBMS is interoperable with other product you have (ie, TP monitor, backup software, a financial package you use, security package, ect).

Whether it scales well for your needs,

Whether it has the niche features you may need (ie. replication, bitmapped indexes, OLAP, OO, etc),

Whether you neck of the woods has enough DBAs in the particular DBMS to support the product over the long term,

Whether the vendor has local presence,

Viability of the vendor/product,

Vendor support track record,

Third party tools availability,

Systems monitoring/management tools available,

Cost.

etc.

Performance is important, but one that keeps improving for all vendors. Leapfrogging keeps changing the picture, but consider the big DBMSs roughly equivalent. It's more an issue in sizing a particular configuration than in choosing a DBMS. You will want to look into performance, but unless things are really out of whack don't base selection on it.

DBMS selection is not trivilal. You may wish to bring in an expert to look into this. The DBMS will, likely, become a cornerstone of you organization that you will have to work with for many years. The long term investment warrants taking a good look at what's out there.

Good luck,

Rick Gebethner
GIT Consulting Received on Mon Dec 16 1996 - 00:00:00 CET

Original text of this message