home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6463 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  6.1 KB
  1. Xref: sparky comp.databases:6463 comp.databases.informix:1841
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!sun!amdcad!weitek!pyramid!infmx!davek
  3. From: davek@informix.com (David Kosenko)
  4. Newsgroups: comp.databases,comp.databases.informix
  5. Subject: Re: Informix vs. Oracle - Summary of Replies
  6. Message-ID: <1992Aug31.155620.11127@informix.com>
  7. Date: 31 Aug 92 15:56:20 GMT
  8. References: <1992Aug28.184837.7374@risky.ecs.umass.edu>
  9. Sender: news@informix.com (Usenet News)
  10. Organization: Informix Software, Inc.
  11. Lines: 136
  12.  
  13. Mathew J Mathews writes:
  14. >
  15. >Hi all -
  16. >
  17. >Here is the compiled list of replies I received.  It will be posted and
  18. >mailed to all those who requested a copy.  Thanks again for the info.
  19. >The revised score turned out to be a little closer than a gazillion to 1:
  20. >
  21. >    Oracle:        9
  22. >    Informix:    2
  23. >
  24. >Actually, there were a few more in favor of Oracle that I omitted.  
  25. >Sorry if I overlooked anyone in this list.
  26.  
  27.  
  28. There are a few inaccuracies in some of the responses you list, which I will
  29. take the liberty to correct.  I will also comment on where future releases of
  30. Informix servers (within the next year) will address some of the "shotcomings"
  31. mentioned.
  32.  
  33. >From: garth@comm.mot.com  (Garth Kennedy)
  34. >Date: Thu, 27 Aug 92 7:58:29 CDT
  35. >
  36. >Well, Informix hasn't been in here trying to give us that line recently.  We 
  37. >are in the process of evaluating alternatives (technical and other) for a LARGE 
  38. >manufacturing system. At the moment, we are going through a first pass 
  39. >evaluation of various DBMS vendor products. In summary, our requirements are 
  40. >for a widely distributed system operating on whatever hardware is locally 
  41. >available. (Oh did I mention the system could be any where on the face of the 
  42. >earth!) The system must be scaleable so that an individual node, run on any 
  43. >thing from a PC to a mainframe or other "large specialized box".  Anyway, that 
  44. >is a very simplified view of the high level requirements.  To date (remember 
  45. >high level) Informix does not have the following:
  46. >
  47. >  1. Procedural SQL
  48.  
  49. Technically this is true (i.e., we do not support procedural constructs in
  50. the SQL language itself).  Note that SQL, as defined by the ANSI committee
  51. does not include procedural elements.  However, when stored procedures and
  52. 4gl are thrown in, this ceases to be true.
  53.  
  54. >  2. They do not normally row lock, mostly page locking
  55.  
  56. This is a misrepresentation.  Informix-OnLine supports both row and page
  57. level locking (and you do not have to buy an add-on package to get row
  58. level locking, unlike Oracle).  The DBA decides which to use when they
  59. create or alter the table.  The *default* mode is page level, as it is
  60. the mode DB2 uses.  So "mostly page locking" is only the case when the
  61. DBA chooses page locking, or simply doesn't bother to specify.  Our
  62. system catalogs are always locked at the row level.
  63.  
  64. >  3. It is not clear how they handle deadlocks
  65.  
  66. To whom?  It is rather simple, if you understand our shared memory and
  67. lock table structure.  Distributed deadlocks are detected differently than 
  68. local-only access, but both can be described and understood without a PhD.
  69.  
  70. >  4. Stored procedures do not seem to be supported.
  71.  
  72. Our 5.0 release (currently shipping on many platforms) supports a robust
  73. stored procedure functionality.
  74.  
  75. >  5. You are limited to 32,000 tables (OK even we wont get that large !)
  76.  
  77. You are limited to 32,000 *simultaneously open* tables.  There is no limit
  78. as to the number of tables you can create in an OnLine system.
  79.  
  80. >  6. The security does not appear to have the flexibility of Oracle v7
  81.  
  82. As I am not familiar with Oracle's security, so I cannot comment on this.
  83.  
  84. >  7. The support of multiple user languages appears to be weak.
  85.  
  86. If you mean embedded SQL, we support C, Cobol, and ADA.  I believe we had
  87. planned to offer Fortran, but dropped it due to lack of interest.
  88.  
  89. >  8. Global naming (of DB objects) appears to be missing
  90.  
  91. I don't know what you mean by this, exactly.  It sounds like some sort of
  92. global data dictionary, which it is true we do not support.
  93.  
  94. >  9. The coupling of distributed DBs is stronger than we would like.
  95.  
  96. Hmm.  I rather thought our coupling was anything but strong.  There is no
  97. dependence between systems in a distributed environment.
  98.  
  99. > 10. Not having the ability to take snapshots of tables (for purposes of 
  100. >     replication) is a problem.
  101.  
  102. 6.0 of OnLine will include full support for hot-site backups.  While this
  103. may not be what you were looking for, it does solve many of the problems
  104. that snapshots are used for.
  105.  
  106. > 11. It appears that triggers are not fully supported.
  107.  
  108. 5.01 of OnLine will include support for triggers.
  109.  
  110. > 12. Their server is single threaded.
  111.  
  112. 6.0 of OnLine will be a muti-threaded, multi-server version.
  113.  
  114. > 13. Support of multiple "foreign" user languages on a per-session basis may be
  115. >an issue.
  116.  
  117. 6.0 will include NLS support.  I don't know the details of it to be able to
  118. say if it will allow different languages (on the same platform) on a per-session
  119. basis.
  120.  
  121. > 14. The DBA tool set in Informix is no where near as supportive as that in
  122. >Oracle.
  123.  
  124. As I am not familiar with Oracle's DBA tools, I can't make a comparision.  We
  125. do support a form/menu based interface (tbmonitor) as well as a utility based
  126. interface (tbinit, tbmode, tbspaces, tbparams, tbtape), giving users a lot
  127. of flexibility in how to handle administration.
  128.  
  129. >Basically, Informix v5 doesn't handle a truly distributed environment as well 
  130. >as Oracle v7.   
  131.  
  132. I'd be interested in hearing some details on this.  In what ways does
  133. Oracle work better?  I am not seeking "justification", but real info.
  134. We can't make it better unless we know what needs improvement.
  135.  
  136. (On our performance):
  137. >
  138. >This has been gained by completely bypassing the operating system and playing 
  139. >games. (If you ever have to chase one of those problems ...)
  140.  
  141. Using shared memory and raw disk access is hardly "playing games".
  142.  
  143. Dave
  144. -- 
  145. Disclaimer: These opinions are not those of Informix Software, Inc.
  146. **************************************************************************
  147. The heart and the mind on a parallel course, never the two shall meet.
  148.                         -E. Saliers
  149.