home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / database / 5846 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  3.4 KB
  1. Path: sparky!uunet!darwin.sura.net!mips!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!chx400!sicsun!disuns2!liasun7.epfl.ch!baechler
  2. From: baechler@liasun7.epfl.ch (Emmanuel Baechler)
  3. Newsgroups: comp.databases
  4. Subject: Re: Looking for a USABLE database
  5. Message-ID: <4430@disuns2.epfl.ch>
  6. Date: 30 Jul 92 17:32:22 GMT
  7. References: <1992Jul22.180503.27010@homebase.vistachrome.com> <l6v00iINN8qf@jethro.Corp.Sun.COM> <4352@disuns2.epfl.ch> <1992Jul28.140922.8573@sdf.lonestar.org>
  8. Sender: news@disuns2.epfl.ch
  9. Organization: Ecole Polytechnique Federale de Lausanne
  10. Lines: 54
  11. Nntp-Posting-Host: liasun7.epfl.ch
  12.  
  13. In article <1992Jul28.140922.8573@sdf.lonestar.org>, abledsoe@sdf.lonestar.org (Al Bledsoe) writes:
  14.  
  15. |> 
  16. |> >  this is totally unacceptable: labs frequently add new tests, or add COMBINED
  17. |> >  tests (based on existing ones), and this means the addition of new columns.
  18. |> 
  19. |> Uh, have you read anything about relational database theory?
  20.  
  21. I am definitely not an expert about relational database theory (my own field is
  22. AI) but I have read quite a bit about that. The fact is that the doctors  and the
  23. people of the labs regulary create new analyses and want to integrate them in
  24. their result sheets, period. They did not hear anything about relational
  25. databases, they don't want to hear anything about that, they want to be able
  26. to enter new columns on their result sheets and these result sheets are represented by tables in most of the labs.
  27.  
  28. |> I've worked in the health field here in Texas since 1975,  doctors are not
  29. |> standard users!!
  30.  
  31. Maybe yours have a different attitude, that's happy for you. A few of our doctors
  32. are quite educated about computers, but this is definitely not the case of the
  33. majority.
  34.  
  35. |> The ANSI MUMPS database/language has for years and years accomplished your
  36. |> task in a very efficient manner.  The U.S. VA laboratory system was written
  37. |> with MUMPS (see DEC's DSM product info).  I now work for a laboratory vendor
  38. |> that uses PICK or UniVerse's PICKeese running on UNIX servers such as
  39. |> Sequent or IBM's RS/6000 or HP's 9000/857's etc.
  40. |> 
  41. |> These database vendors are just now discovering the Open world as they
  42. |> emerge from their vertical niches.  Intersystems is a MUMPS vendor that
  43. |> markets a product called M/SQL, hiding the name MUMPS and flouting
  44. |> their 4GL-like frontend.  UniVerse 7.0 by Vmark is doing the same thing
  45. |> by embedding SQL and creating a global dictionary to the relational
  46. |> world.
  47. |> 
  48. |> So,  there is no lack for tools to create efficient and well interfaced
  49. |> applications for the medical community.   Byte magazine May 1992 gives
  50. |> credibilty to the view that RDBMS's have had their chance.  Combining
  51. |> what was learned through them with what has been demonstrated through
  52. |> such DBMS's as MUMPS and PICK will find new functional products from
  53. |> vendors that address the real world of weird users like doctors.
  54. |> 
  55. |> Hint:  try Advanced Revelation in a client/server design with UniVerse.
  56.  
  57. Thank you very much for yourt answer and sorry for the delay of my answer.
  58.  
  59. -- 
  60. Emmanuel Baechler.                        | Tel.: ++41-21-693-2732
  61. Laboratoire d'Intelligence Artificielle   | e-mail: baechler@lia.di.epfl.ch
  62. Ecole Polytechnique Federale de Lausanne  |     or: baechler@liasun6.epfl.ch
  63. MA-Ecublens                               | Standard Disclaimer
  64. CH-1015 Lausanne    Switzerland
  65.  
  66. Ban the bomb. Save the world for conventional warfare.
  67.