Re: Informix, Sybase, Oracle or MS SQL server

From: J.Masino/T.Larson <tlarson_at_ari.net>
Date: 1996/04/20
Message-ID: <4laf6e$46q_at_ari.ari.net>


Michael Cowden (cowden_at_tc.net) wrote:
:
: We are trying to find a workgroup database server to run on Intel/NT
: that will be accessed from an SCO UnixWare 2.1 server and an SGI Irix
: 5.3 server. The Irix machine is a webserver and will perform queries on
: the database. The UnixWare machine is an IVR (Integrated Voice Response
: unit--an automated attendant used to process incoming telephone calls
: and such). The UnixWare machine will also query the database.
: Additionally, reports will be run on the database--sporadically.
:
: We will also need Embedded SQL for SCO Unixware 2.1's C compiler and the
: IRIX 5.3 C compiler.
:
: 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.

: 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'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.

: 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.

All valid points. :-)

				Good luck,
				Teresa Larson

     ____________________________________________________________________
    /  Teresa A. Larson                   ISUG Electronic Media Chair   /
   /  Bell Atlantic                            Voice: (703) 769-8662   /
  /  900 South Walter Reed Drive         Fax:   (703) 769-8415/8416   /
 /  Arlington, VA  22204             bfr45rp_at_IS001685.bell-atl.com   /
/___________________________________________________________________/
                        #include <std_disclaimer>
Received on Sat Apr 20 1996 - 00:00:00 CEST

Original text of this message