Unify vs Informix & Oracle

SallyBoyz * aol.com wrote: > Tim I noticed your online resume. I was wondering if you could share > with me > any thoughts about the Unify 2000 product and its shortcoming vs. > competition. > Thanks, Sal Comunale. Sorry, it took me so long to respond to your email... it got lost in my inbox! Basically, the only major user of Unify appears to have been the United States Air Force. In almost every sales call TSC (http://www.tsc-corp.com) made to sell our (then) Unify-based product, the prospect had to be told who Unify was. Everyone asked about Informix or Oracle availability, but we only offered Unify for the longest time. In our (TSC's) experience, we found the number one operational defect to be the fact that U2000 clients communicate with the server via shared memory, and it is possible (indeed, at one point we would have called it common) for client programs to write stuff into that shared memory segment that causes one or more of the server processes (fmdmn, lgdmn, lkdmn, & cldmn) to coredump, with significant gymnastics required for recovery. Due to market demands, we migrated the application (AMIS-2000, described at http://www.tsc-corp.com/amis.htm) to Informix 5.0, and later to 7.x, and were rewarded by Informix's superior stability. After the port, I left the company for some contract work, where I learned more about Informix, and went back to TSC, where I was able to apply my new knowledge of Informix to the AMIS-2000 project for even greater performance (using dynamic SQL, & caching statement-prepare-ids). I left the company again, and have had two more contracts dealing with far larger datasets under Informix, and am definitely an Informix fan! My opinions on Oracle are solely based on my part-time work this year for TSC (yes after I quit twice), during which I ported the application to Oracle 8, which spanned almost 30 Saturdays. I found Oracle's lack of native integer, smallint, float and double types to be somewhat alarming (everything has to be a NUMBER(width,precision) format, similar to Unify, which I considered a step backwards). While Informix has 5 or 6 different DATE types, Oracle only has a DATETIME time, which combines both into one, and cannot be split into only a DATE or TIME field. Initially, we tried to port to Oracle 7, and we found it does not support more than one large-binary object per row. This made Oracle 7 totally unusable for AMIS, but Oracle 8 has two new datatypes called BLOB and CLOB (binary/character large objects), of which there was no per-row limitation. While the specs for the supporting tools promised more flexibility in some ways, I found them more difficult to use than Informix, which throws in some great conveniences. Example 1: While the sqlloader's extensive control file format for handling loads would seem to handle almost any input stream, there were no examples to work with or re-use, and it took considerable shell-scripting to get it to load a simple pipe-delimited file that Informix recognizes immediately. Example 2: Informix provides a datatype value called SERIAL that provides an ever-increasing integer values for each row automatically. This was the closest thing to Unify's rowids that we could find on Informix, (yes, I know about the Informix 'rowid' psuedo-column, but Informix recommends not to use it, because it's not _really_ a row id on fragmented tables) and AMIS-2000 depends heavily on it. The only way I found to duplicate this feature under Oracle was to write an INSERT TRIGGER statement that checked for a zero value in my 'row_id' column, and do a 'select sequence.nextval from dual;' to pull a counter off another database object called a "sequence", and then plug that into the row just before the insert. I didn't expect to write such a tome in response to your query, but since I have I am also posting it to the newsgroups for public consumption. Best regards, Tim -- ====================================================== Tim Jones --- Technical Resource Connection, Tampa, FL #include <disclaimer.h> - Subsidiary of Perot Systems http://www.worldfax.com/~tim - http://www.trcinc.com ======================================================