Re: Informix vs. Oracle - Summary of Replies

Mathew J Mathews writes: > >Hi all - > >Here is the compiled list of replies I received. It will be posted and >mailed to all those who requested a copy. Thanks again for the info. >The revised score turned out to be a little closer than a gazillion to 1: > > Oracle: 9 > Informix: 2 > >Actually, there were a few more in favor of Oracle that I omitted. >Sorry if I overlooked anyone in this list. There are a few inaccuracies in some of the responses you list, which I will take the liberty to correct. I will also comment on where future releases of Informix servers (within the next year) will address some of the "shotcomings" mentioned. >From: garth@comm.mot.com (Garth Kennedy) >Date: Thu, 27 Aug 92 7:58:29 CDT > >Well, Informix hasn't been in here trying to give us that line recently. We >are in the process of evaluating alternatives (technical and other) for a LARGE >manufacturing system. At the moment, we are going through a first pass >evaluation of various DBMS vendor products. In summary, our requirements are >for a widely distributed system operating on whatever hardware is locally >available. (Oh did I mention the system could be any where on the face of the >earth!) The system must be scaleable so that an individual node, run on any >thing from a PC to a mainframe or other "large specialized box". Anyway, that >is a very simplified view of the high level requirements. To date (remember >high level) Informix does not have the following: > > 1. Procedural SQL Technically this is true (i.e., we do not support procedural constructs in the SQL language itself). Note that SQL, as defined by the ANSI committee does not include procedural elements. However, when stored procedures and 4gl are thrown in, this ceases to be true. > 2. They do not normally row lock, mostly page locking This is a misrepresentation. Informix-OnLine supports both row and page level locking (and you do not have to buy an add-on package to get row level locking, unlike Oracle). The DBA decides which to use when they create or alter the table. The *default* mode is page level, as it is the mode DB2 uses. So "mostly page locking" is only the case when the DBA chooses page locking, or simply doesn't bother to specify. Our system catalogs are always locked at the row level. > 3. It is not clear how they handle deadlocks To whom? It is rather simple, if you understand our shared memory and lock table structure. Distributed deadlocks are detected differently than local-only access, but both can be described and understood without a PhD. > 4. Stored procedures do not seem to be supported. Our 5.0 release (currently shipping on many platforms) supports a robust stored procedure functionality. > 5. You are limited to 32,000 tables (OK even we wont get that large !) You are limited to 32,000 *simultaneously open* tables. There is no limit as to the number of tables you can create in an OnLine system. > 6. The security does not appear to have the flexibility of Oracle v7 As I am not familiar with Oracle's security, so I cannot comment on this. > 7. The support of multiple user languages appears to be weak. If you mean embedded SQL, we support C, Cobol, and ADA. I believe we had planned to offer Fortran, but dropped it due to lack of interest. > 8. Global naming (of DB objects) appears to be missing I don't know what you mean by this, exactly. It sounds like some sort of global data dictionary, which it is true we do not support. > 9. The coupling of distributed DBs is stronger than we would like. Hmm. I rather thought our coupling was anything but strong. There is no dependence between systems in a distributed environment. > 10. Not having the ability to take snapshots of tables (for purposes of > replication) is a problem. 6.0 of OnLine will include full support for hot-site backups. While this may not be what you were looking for, it does solve many of the problems that snapshots are used for. > 11. It appears that triggers are not fully supported. 5.01 of OnLine will include support for triggers. > 12. Their server is single threaded. 6.0 of OnLine will be a muti-threaded, multi-server version. > 13. Support of multiple "foreign" user languages on a per-session basis may be >an issue. 6.0 will include NLS support. I don't know the details of it to be able to say if it will allow different languages (on the same platform) on a per-session basis. > 14. The DBA tool set in Informix is no where near as supportive as that in >Oracle. As I am not familiar with Oracle's DBA tools, I can't make a comparision. We do support a form/menu based interface (tbmonitor) as well as a utility based interface (tbinit, tbmode, tbspaces, tbparams, tbtape), giving users a lot of flexibility in how to handle administration. >Basically, Informix v5 doesn't handle a truly distributed environment as well >as Oracle v7. I'd be interested in hearing some details on this. In what ways does Oracle work better? I am not seeking "justification", but real info. We can't make it better unless we know what needs improvement. (On our performance): > >This has been gained by completely bypassing the operating system and playing >games. (If you ever have to chase one of those problems ...) Using shared memory and raw disk access is hardly "playing games". Dave -- Disclaimer: These opinions are not those of Informix Software, Inc. ************************************************************************** The heart and the mind on a parallel course, never the two shall meet. -E. Saliers