Re: Informix, Sybase, Oracle or MS SQL server

At 03:23 PM 4/24/96 GMT, cpc0000@ibm.net wrote: }tlarson@ari.net (J.Masino/T.Larson) wrote: }>Michael Cowden (cowden@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@a1.tch.harvard.edu }Applications Specialist Portal: cpc@shell.portal.com }Children's Hospital Home: cpc0000@ibm.net }#include <std_disclaimer.h> Wk Phone:(617) 355-8401 } }