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

WhRick Gebethner wrote:
>
> 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
Who did You Choose in these cases (version appreciated) Received on Wed Dec 18 1996 - 00:00:00 CET