Re: Informix, Sybase, Oracle or MS SQL server

From: Chris Cebelenski <cpc0000_at_ibm.net>
Date: 1996/04/24
Message-ID: <4llgt5$7ob_at_netope.harvard.edu>


tlarson_at_ari.net (J.Masino/T.Larson) wrote:
>Michael Cowden (cowden_at_tc.net) wrote:
 [...]
>: I'm wondering which one of these servers is the best to go with. Here's
>: what I found so far.

>:
>: Oracle:
>: Seems to offer alot of what we need, but you must take a
>: database of line to back it up--this is a problem. Also, I've yet to
>: speak with a technical person at Oracle--they seem to just try to get by
>: with their name. Also, They are a little more expensive and I don't
>: care much for their internet strategy (creating a webserver to compete
>: with Netscape and others rather than working with webserver developers
>: as does Sybase). Also, they seem to be more proprietary than Sybase or
>: Informix.
>
>If you read their news group you will find you aren't alone in your
>response to their tech support. It seems to be a cycle for all vendors.
>As for their proprietary nature, I have found that is just Oracle's approach.
>They are a product bundling type of company, which is a good thing for
>people who like to do one-stop-shopping.

Oracle is a very nice database for large to very large requirements. It scales nicely, and has just about all the bells and whistles you'd want. On the flip side, tech support isn't all it should be, and some tools are getting a bit antiquated. Also, some of the newer windows tools are taking a very long time to mature.
>
>: Sybase:
>: Liked dealing with them but it seems that they have some serious
>: problems--no row-level locking, no two-phase commit. I like their
>: web.sql product--but it's not out for IRIX yet. Aside from these issues
>: I am very happy with them, but these are serious issues.
>
>There's another thread in here kicking around row level vs page level locking.
>It pops up periodically. I have not found page level locking to be a problem.
>It minimizes the work the server has to do which is good for performance.
>2K is usually just a few rows (usually), and your database design will
>frequently handle it (carefully choose what you create your clustered indexes
>on, if you need them, to avoid insert hot spots, bundle transactions (begin
>and end transaction) so that updates don't hold locks for extended amounts
>of time -- that kind of thing).

I've run into places where row level locking was absolutely critical, but yes you could do without it quite a bit of the time. For quick update, transaction type systems, it works OK, but I've done some compute intensive data warehousing operations, and for this it can be troublesome if you hold locks for a long time.

>
>I'm confused about what you say about the two-phased commit. Sybase supports
>two-phased commit capability through Open Client. Of course, this is
>client-side calls rather than server-side enforcement. So their
>implementation may not be optimal for your plans, but it is there if that's
>your concern.
>
>: Informix:
>: Just getting familiar with their offering. They look good, but
>: I still need to find out more. They don't appear to have the same
>: problems that Sybase has. They also do not have anything out for the
>: web side (except for the CGI kit). LiveWire Pro for Netscape is not yet
>: available but will offer alot of what we need for the database
>: integration from the web. I'm interested in finding out more about
>: these guys. They look like a good alternative.
>
>I haven't worked with it. I've read a lot and it sounds like they are doing
>good things.

I've heard nice things, especially about their superier debugging and diagnositic tools. Don't know much about it really.

>
>: MS SQL Server:
>: My initial inclination (from dealing with MS in the past) is NO
>: WAY. Serious issues include--access from Unixware and Irix.
>: Scalability--with MS it looks like you are stuck with MS the whole way.
>

Without opening myself up too far, surfice it to say that the MS product has some toubles scaling. I've heard that somewhere around 15M rows it starts to break down. That may seem like a lot of rows, but it really isn't. I have tables that blow past that number with ease, especially large financial transaction and medical lab results tables.

Chris


Chris Cebelenski               CH:      cebelenski_at_a1.tch.harvard.edu
Applications Specialist        Portal:  cpc_at_shell.portal.com
Children's Hospital            Home:    cpc0000_at_ibm.net
#include <std_disclaimer.h> Wk Phone:(617) 355-8401 Received on Wed Apr 24 1996 - 00:00:00 CEST

Original text of this message