Re: Informix vs Sybase(Urgent)

Frank Chao wrote: > Some consulting company is trying to persuade us to switch my group > from Informix to Sybase, and they gave us the following arguments. Do > you know if the following arguments are true? Which is better choice? I don't pretend to be an Informix expert but I know enough to know that their arguments appear specious. > 1. Informix doesn't support a fixed-width binary datatype, like the > Informix ^^^^^^^^ Do you/they mean Sybase here? > "binary" type, or the Oracle "RAW" type. The primary key value we'd > like to > use is most efficiently represented using a binary datatype. As a > workaround, we can represent the value as text, using the Informix > "CHAR" type, but in doing so we take a performance hit. I'd like to know why their primary key value is best represented in a binary datatype. With Sybase, I would have used either an int or a numeric. I'm sure Informix has equivalents. A char datatype would have slight performance issues but its choice isn't as dumb as binary for a key value. > 2. Informix doesn't support the type of stored procedure construct we > need. > Though Informix does support stored procs, it doesn't seem to support a > form > of stored proc which lets you rapidly evaluate a query, and then return > the > result set as a series of rows in the same fashion that a SELECT might. > Currently, "Hot List" calculation is being done in the database using a > single SQL query. In development, we implemented this query as a Sybase > stored procedure for maximum efficiency. Since we couldn't find an > appropriate mapping for this functionality in Informix, we're evaluating > the > "Hot List" query like any other SQL statement---which isn't as efficient > as we'd like. I'm not sure what they're getting at here. If all they are doing is coding a simple select thru a stored procedure, I'm sure Informix is more than capable of coping. > 3. Informix doesn't support any mechanism for limiting the number of > rows > fetched by a query (Sybase does this using the "set rowcount" feature). > This > is somewhat alarming since some queries could potentially select the > entire > database. There isn't a very good workaround for this problem, that I'm > aware of. At this point, I'm getting suspicious of their level of competence. If they have to rely on restricting the size of a resultant row set, you'd have to ask how badly designed is their database model and application(s). > The other reasons we're recommending Sybase: > > 1. Sybase is case-sensitive, so it won't be mangling our table and > column > names like Informix (lowercases everything) and Oracle (uppercases > everything). Merely annoying, but it's another tidbit in favor of > Sybase. Sybase supports several case models. What happens if it was configured to be case-insensitive? > 2. There are several public domain database access tools for Sybase > (dsql, > squish, etc) which are more powerful and user-friendly than the Informix > alternatives (dbaccess). Again, this is merely an issue of convenience > during development. There are also business rules to deal with and support issues with public domain programs. Does your organisation allow the use of unsupported public domain programs? What of issues with viruses etc. If they weren't allowed to use dsql or sqsh due to these considerations they'd just be stuck with isql which is as woeful as dbaccess. It seems to me that they are just trying to put up a very weak case against Informix because they aren't familiar with it. (But they don't seem to be that much more familiar with Sybase either.) -am