home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / database / 5821 < prev    next >
Encoding:
Text File  |  1992-07-29  |  3.9 KB  |  92 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!cs.utexas.edu!convex!egsner!adaptex!sdf!abledsoe
  3. From: abledsoe@sdf.lonestar.org (Al Bledsoe)
  4. Subject: Re: Looking for a USABLE database
  5. Message-ID: <1992Jul28.140922.8573@sdf.lonestar.org>
  6. Organization: sdf Public Access UNIX, Dallas--unrestricted free shell access
  7. References: <1992Jul22.180503.27010@homebase.vistachrome.com> <l6v00iINN8qf@jethro.Corp.Sun.COM> <4352@disuns2.epfl.ch>
  8. Date: Tue, 28 Jul 1992 14:09:22 GMT
  9. Lines: 81
  10.  
  11. In article <4352@disuns2.epfl.ch> baechler@liasun7.epfl.ch (Emmanuel Baechler) writes:
  12. >Hi,
  13. >
  14. >I am currently workink with an hospital. My task is to support laboratories and
  15. >their applications. I am also involved in the choice and the integration of new
  16. >applications in our environnment.
  17. >
  18. >To do this I have started to work with databases a few days ago, especially
  19. >with Ingres (version 6.4 on a DG AViiON 310). The least that I can say is that
  20. >I am *TERRIBLY* disappointed. This DBMS is not only extremely slow, it's way of
  21.  
  22. etc. etc. heard this story many times before.
  23.  
  24. >  this is totally unacceptable: labs frequently add new tests, or add COMBINED
  25. >  tests (based on existing ones), and this means the addition of new columns.
  26.  
  27. Uh, have you read anything about relational database theory?
  28.  
  29. >_ The SQL request are *SLOW*, to say the least!
  30. >
  31. >_ there's no environnment allowing "standard users", like lab people or doctors
  32.  
  33. I've worked in the health field here in Texas since 1975,  doctors are not
  34. standard users!!
  35.  
  36. >It is absolutely clear for me that, in this situation, any package based on
  37. >Ingres would be totally rejected by these laboratories. Even worse, they would
  38. >create a *LOT* of anger.
  39.  
  40. Probably.  But one of my projects is to go RDBMS.  The company I am with
  41. now is still recovering from an attempt to go DB2.  So how can I win?
  42.  
  43. >
  44. >So, my questions are the following:
  45. >
  46. >_ Is there, somewhere in the world, a USABLE query (and developpement)
  47. >  enviromments for DBMS like Ingres and ORacle?
  48. >
  49. >_ If so, where can I find them? Is there something in public domain that could
  50. >  be FTPable? Are there good commercial products? Where can I find them?
  51. >
  52. >_ Are there OTHER good multiuser RELATIONAL DBMS? Where can I find Them?
  53. >
  54. >_ Are there good alternatives to RDMS? Are some object-oriented DBMS worth?
  55. >  Are ther environnment usable? Where can I find them?
  56. >
  57. >Any help will be HIGHLY appreciated.
  58. >
  59. The ANSI MUMPS database/language has for years and years accomplished your
  60. task in a very efficient manner.  The U.S. VA laboratory system was written
  61. with MUMPS (see DEC's DSM product info).  I now work for a laboratory vendor
  62. that uses PICK or UniVerse's PICKeese running on UNIX servers such as
  63. Sequent or IBM's RS/6000 or HP's 9000/857's etc.
  64.  
  65. These database vendors are just now discovering the Open world as they
  66. emerge from their vertical niches.  Intersystems is a MUMPS vendor that
  67. markets a product called M/SQL, hiding the name MUMPS and flouting
  68. their 4GL-like frontend.  UniVerse 7.0 by Vmark is doing the same thing
  69. by embedding SQL and creating a global dictionary to the relational
  70. world.
  71.  
  72. So,  there is no lack for tools to create efficient and well interfaced
  73. applications for the medical community.   Byte magazine May 1992 gives
  74. credibilty to the view that RDBMS's have had their chance.  Combining
  75. what was learned through them with what has been demonstrated through
  76. such DBMS's as MUMPS and PICK will find new functional products from
  77. vendors that address the real world of weird users like doctors.
  78.  
  79. Hint:  try Advanced Revelation in a client/server design with UniVerse.
  80.  
  81. >-- 
  82. >Emmanuel Baechler.                        | Tel.: ++41-21-314-45-30
  83. >CHUV                                      | e-mail: baechler@lia.di.epfl.ch
  84. >Division Autonome d'informatique          |     or: baechler@liasun6.epfl.ch
  85. >CH-1011 Lausanne    Switzerland      | Standard Disclaimer
  86. ---
  87. Al Bledsoe (214) 349-4025     I'm not a salesman.
  88. NLFC, Inc. ( new LAB FORCE company)  
  89. abledsoe@sdf.lonestar.org
  90.  
  91.  
  92.